Posted on February 14, 2017 at 09:58Using C++ safely is easier than using C safely, in any environment.
I don't know about any particular issues with C++ (as a language) for embedded projects. It's possible that exceptions are not implemented very efficiently and entail a significant runtime penalty. Or not. This may depend on the compiler. I would advise against using RTTI under any almost circumstances (embedded or otherwise). Code using this has always seemed fragile to me.
As with C, dynamic memory allocation can be an issue. Using new and delete is no worse than using malloc() and free(). I never rely on any generic allocator, but use memory pools of fixed sized objects when the need arises. I wrote a really simple template containing an array of T and a singly linked list of pointers to those objects to be the free list. Even better, if you care about such things, overload operator new for T to hide the memory pool implementation from the rest of the code...
I generally avoid the STL for embedded. I'm sure it's very clever and possibly even very space efficient, but I really don't know what's going on under the hood. Tons of dynamic allocation from the heap, I imagine. Obviously you can write your own allocators, but that is a path I am yet to tread.
What do you mean by low memory? I recently wrote something for an MSP430 with 512B RAM and 8kB ROM. I used C. I would like to have tried C++, but it wasn't my call. I don't *know* that C++ would be have been too expensive... Classes are no bigger than equivalent C structs, except they'll have a pointer to the vtable if the class has virtuals. Member functions have a hidden parameter (this), which is equivalent to passing the address of a struct object to a C function. I guess there are default constuctors and whatnot, but these replace the initialisation code you'd put after every struct declaration... It would be an interesting experiment.
