Hacker News Reader

Comment by monocasa | Hacker News Reader

It's worth a chapter in this book IMO.

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.

View on HN

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.

Disabling exceptions has solved this. There are no need for exceptions in the kernel, and the cost is high.

Isn't table-driven stack unwinding cheaper than having a bunch of functions each check an error code and return to their caller?

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.

Reply on news.ycombinator.com