5 ms·

I don't think RAII is a concept complex enough to write a book about it... Probably a blog post or Wikipedia page is enough to explain it fully.

by mbel 9y ago

monocasa 9y ago
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.
- xyzzy_plugh 9y ago
  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.
  - monocasa 9y ago
    > 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.
  - fdsfsafasfdas 9y ago
    Disabling exceptions has solved this. There are no need for exceptions in the kernel, and the cost is high.
    - concede_pluto 9y ago
      Isn't table-driven stack unwinding cheaper than having a bunch of functions each check an error code and return to their caller?
      - monocasa 9y ago
        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.
asveikau 9y ago
If someone writes this ... > 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.

I don't think RAII is a concept complex enough to write a book about it... Probably a blog post or Wikipedia page is enough to explain it fully.

by mbel 9y ago

I don't think RAII is a concept complex enough to write a book about it... Probably a blog post or Wikipedia page is enough to explain it fully.

monocasa 9y ago

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.

xyzzy_plugh 9y ago
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.
- monocasa 9y ago
  > 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.
- fdsfsafasfdas 9y ago
  Disabling exceptions has solved this. There are no need for exceptions in the kernel, and the cost is high.
  - concede_pluto 9y ago
    Isn't table-driven stack unwinding cheaper than having a bunch of functions each check an error code and return to their caller?
    - monocasa 9y ago
      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.

asveikau 9y ago

If someone writes this ... > 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.