I traditionally haven't been the biggest fan of this book. Most of what they list is stuff that just looks like using C++ just for the sake of it, with no real benefit over a C codebase.
For instance they don't appear to use RAII at all, even in places where it's an obvious win (InterruptLock).
As the maintainer of a C++14 proprietary RTOS, it's probably the most convincing argument to the C guys as to why C++ can benefit embedded codebases. Like not being able to forget to re-drop thread priority when you've temporarily increased it.
Or one of my favorite patterns is returning the object representing the temporary higher priority. If the caller doesn't do anything with the return value, the destructor is called and thread priority reverts to what it was. However, it gives you a chance for the caller to hold on to that high priority object, and get more work done essentially atomically.
But the compiler doesn't optimize out the constructor, right? It can't.
In an RTOS of all places, that seems awfully expensive. One generally avoids wasted resources in embedded -- the trade-off is it requires more care during development.
I've never seen RAII work well in an embedded system. Not being able to handle exceptions or errors during destruction ruins everything.
> But the compiler doesn't optimize out the constructor, right? It can't.
> In an RTOS of all places, that seems awfully expensive. One generally avoids wasted resources in embedded -- the trade-off is it requires more care during development.
The compiler has no issues "optimizing out" the constructor in my experience. The asm looks just like the equivalent C in all of the cases I've seen.
> I've never seen RAII work well in an embedded system. Not being able to handle exceptions or errors during destruction ruins everything.
I mean, we disallow exceptions anyway. And we use RAII for objects where there isn't a weird failure case to be handled like my example of thread priority guards.
The practicalities of bare metal programming means that a lot of the time an individual work item has to jump contexts (ie. stacks and register sets) in a way that doesn't map cleanly to C++ style exceptions.
> I haven't found many practical guides or tutorials of how to use C++ superiority and boost development process compared to conventional approach of using “C” programming language.
... and does not mention RAII in their quest to write such a guide, they have seriously failed at their goal.
For instance they don't appear to use RAII at all, even in places where it's an obvious win (InterruptLock).