4 ms·
Dynamic allocation is banned for many bare metal applications. Dynamic allocations make it harder to reason about worst-case memory usage, especially with fragm
by jononor 9y ago
Dynamic allocation is banned for many bare metal applications. Dynamic allocations make it harder to reason about worst-case memory usage, especially with fragmentation.
I find the improved initializers in C++11 a very nice addition for such usecases. One can use a struct for the application state (with struct/std::array members etc), and initialize it statically in one statement. Nicely declarative, space/code efficient, and with good type-safety.
- com2kid 9y ago> Dynamic allocation is banned for many bare metal applications. Dynamic allocations make it harder to reason about worst-case memory usage, especially with fragmentation. This right here. There is no STL in true embedded C++ apps. It is possible to make compile time allocated templated data structures, they work just fine, but they aren't the STL by any stretch. IMHO this type of C++ is much better to use. Having to plan ahead for worst case memory usage for all classes and statically allocate memory at compile time simplifies a LOT of code. Pointers don't disappear on you (although contents can obviously change!), and removing all the code handling alloc and de-alloc removes a huge chunk of code. Honestly having gone from "C with classes C++" to "full on C++11", I'm missing the C with classes. Fewer ways to abstract means finding the code that is actually running becomes a lot easier. Also having code size be an issue means people don't get to write their own set of abstraction layers that end up having only 1 or 2 concrete implementations. :/