4 ms·
In a lot of embedded systems, the penalties associated with RAII and other runtime goodies like vtables are often prohibitive, so they're commonly disabled. It'
by stevenhuang 8y ago
In a lot of embedded systems, the penalties associated with RAII and other runtime goodies like vtables are often prohibitive, so they're commonly disabled. It's a factor in why C continues to be the lingua franca instead of C++ in the embedded space--it's simpler and still "good enough" not to warrant a switch-over to C++ (in addition to many other reasons).
The compile-time features of C++ are a great reason to switch over though, and for devices with greater resources, C++ becomes an even better fit.
- Gibbon1 8y ago> and for devices with greater resources, C++ becomes an even better fit. It doesn't take having much more resources before switching away from C++ is a vastly better option though.
- jcelerier 8y ago> the penalties associated with RAII and .... there are 0 penalties associated with RAII. struct my_interrupt { my_interrupt() { vendor_specific_horrible_stuff(0x237ABC); } ~my_interrupt() { if(whatever) vendor_specific_horrible_stuff(0x237BAC); } }; void f() { my_interrupt is_enabled; // do stuff } will translate to exactly the same assembly than void f() { vendor_specific_horrible_stuff(0x237ABC); // do stuff if(whatever) vendor_specific_horrible_stuff(0x237BAC); }
- proverbialbunny 8y agoSpeed is not the issue for embedded development. The problem with C++ is it has a few language features that are not deterministic making standard C++ not ideal for real time code. Most of the stl uses these features, so most vanilla C++ is disabled for many embedded environments. Also, there is a push for C++23 to have deterministic exception handling. If this passes (and it likely will) most of the stl will become available for embedded, and when that time comes C++ is going to become far more of a viable option than it currently is. If you're curious you can read about it here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...
- monocasa 8y agoExceptions aren't what's keeping people from using the still in embedded context's, it's the dynamic memory management.
- proverbialbunny 8y agoDynamic memory management? What part of C++ do you mean? I'm unfamiliar. Surely not unique_ptr, I would think. C allocates on the heap too, so I must be misunderstanding.
- monocasa 8y agoPretty much all heap allocation outside of init time is verboten in embedded contexts, whether C or C++. So yes, the regular unique_ptr, vector, some lambdas that heap allocated their captured, etc. You're not allowed to use malloc in C either. Check out MISRA C, and the JSF C++ Standard for examples of embedded code standards.
- stevenhuang 8y agoAgree with what you said, and that's a very interesting paper--thanks for the link!
- aseipp 8y agoNobody who uses C++ for embedded development uses or cares about the STL though, and its absence isn't exactly surprising for a number of reasons... The selling point is features like RAII and templates, which can greatly reduce duplication and improve readability. Sure, you technically can't use the STL for whatever reasons, but practically it doesn't actually matter at all, and its absence comes with the territory for everyone involved. Being able to use more of the STL in contexts like this would be nice for future projects, perhaps.
- BenFrantzDale 8y agoKeep in mind, the STL isn't limited to the containers, there are tons of algorithms that are very useful for embedded programming that don't throw exceptions, are vetted, and are as efficient as hand-written algorithms.
- monocasa 8y agoNobody disables RAII or vtables ( and I don't know how you would 'disable' those). We do disable RTTI and exceptions though.
- stevenhuang 8y agoYou're right, I was thinking about RTTI there, and wrong phrasing for vtables (should have said to avoid the virtual keyword and dynamic binding).
- monocasa 8y agoI mean, even virtual dispatch is fine if you opt in to it. Pointer indirection costs way less relatively on embedded systems than big boy systems with DRAM and caches.