4 ms·
The STL does lead to increased memory consumption and code bloat, however. It is wholly unacceptable to use the STL in any embedded system, or kernel-level OS c
by DaveMebs 16y ago
The STL does lead to increased memory consumption and code bloat, however. It is wholly unacceptable to use the STL in any embedded system, or kernel-level OS code.
- blub 16y agoThat is incorrect. It is not used (or rather a standard STL is not used) because it depends on exceptions and dynamic memory allocations. The STL code is highly optimized and there should be no technical reason why it would consume more memory or lead to code bloat.
- zwieback 16y agoMy experience exactly. The STL==code-bloat argument is really not valid but avoiding STL in smaller embedded systems due to exceptions+new/malloc is reasonable. Once you have a MMU and megabytes of RAM the balance may shift but you still have to worry about realtime behavior.
- jimwise 16y agoRight. This is why Ada, which has always paid special attention to the needs of embedded systems, provides so many guarantees about what program behaviors are and are not allowed to cause allocations or exceptions. The upcoming Ada 2012 standard even includes versions of Ada 2005's collection classes which are allocation-free (read: pre-allocated to a size specified at creation time, and guaranteed not to perform allocation after that point). Ada's generic programming was a big influence on Stepanov's design of what became the STL (the first versions were a port of work he had done under Ada). Ironically, the Ada standards process moved so slowly that by the time Ada grew standards-mandated generic collection classes (previously this was something all vendors provided as an extension), it had time to learn the lessons of STL. (Not a knock on STL, by the way -- STL's implementors have learned a lot over the life of the standard as well.)