I haven't read the article yet, but it's standard operating procedure for embedded. * No exceptions, ever * No RTTI, ever * Compile with -Os * Limit STL to

I haven't read the article yet, but it's standard operating procedure for embedded. * No exceptions, ever * No RTTI, ever * Compile with -Os * Limit STL to the non-allocating, non-throwing parts * Don't allow heap usage * Link against the C standard library so you don't get accidental heap allocations from lambdas with large capture specs and static construction and destruction fail to link * Use alternatives to std::function (which while easy is very large and very slow) * Limit the use of virtual functions (some people suggest eliminating them altogether but I feel like that's a bridge too far). * Avoid inlining functions if you're not sure that they reduce down to something trivial. I've saved a kilobyte or two by moving some particularly large, commonly used functions into separate translation units so that the compiler couldn't inline them. * Look at and track your space utilization commit by commit. If the data segment goes up unexpectedly, revisit what you're doing. You may have unwittingly allocated a big block for something. Similar for the code segment. You get used to the constraints. Type safety, templates, and compile time programming make it 10 times better than C for the purpose in my experience. The only reason to use C is if your C++ compiler is garbage (which is often true for the tiny low powered processors). But if it's ARM you probably have access to a modern compiler and the only reason to stick with C is inertia. I've been programming with embedded C++ for ten years and every time I have to poke into the C part of the codebase I end up hating life.