4 ms·

I was surprised not to see anything about RAII techniques (http://en.cppreference.com/w/cpp/language/raii http://en.cppreference.com/w/cpp/language/raii). Tigh

• taneq 8y ago
  Often in embedded systems, it's actually less of an issue, because you don't need to "acquire" resources - you have the run of the hardware and you're not sharing any devices with any other code. Likewise, you don't need to keep memory free for other applications to use, so there's a strong tendency to just allocate everything statically. It's simpler and more reliable.
  • monocasa 8y ago
    No, RAII is great on embedded systems with static resource allocation. Grabbing realtime priority or disabling interrupts with a lock_guard so you can't forget to release is a god send.
    • taneq 8y ago
      True, there are a few cases where it's useful, and it's great for those.
• stevenhuang 8y ago
  In a lot of embedded systems, the penalties associated with RAII and other runtime goodies like vtables are often prohibitive, so they're commonly disabled. It's a factor in why C continues to be the lingua franca instead of C++ in the embedded space--it's simpler and still "good enough" not to warrant a switch-over to C++ (in addition to many other reasons). The compile-time features of C++ are a great reason to switch over though, and for devices with greater resources, C++ becomes an even better fit.
  • Gibbon1 8y ago
    > and for devices with greater resources, C++ becomes an even better fit. It doesn't take having much more resources before switching away from C++ is a vastly better option though.
  • jcelerier 8y ago
    > the penalties associated with RAII and .... there are 0 penalties associated with RAII. struct my_interrupt { my_interrupt() { vendor_specific_horrible_stuff(0x237ABC); } ~my_interrupt() { if(whatever) vendor_specific_horrible_stuff(0x237BAC); } }; void f() { my_interrupt is_enabled; // do stuff } will translate to exactly the same assembly than void f() { vendor_specific_horrible_stuff(0x237ABC); // do stuff if(whatever) vendor_specific_horrible_stuff(0x237BAC); }
  • proverbialbunny 8y ago
    Speed is not the issue for embedded development. The problem with C++ is it has a few language features that are not deterministic making standard C++ not ideal for real time code. Most of the stl uses these features, so most vanilla C++ is disabled for many embedded environments. Also, there is a push for C++23 to have deterministic exception handling. If this passes (and it likely will) most of the stl will become available for embedded, and when that time comes C++ is going to become far more of a viable option than it currently is. If you're curious you can read about it here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...
    • monocasa 8y ago
      Exceptions aren't what's keeping people from using the still in embedded context's, it's the dynamic memory management.
      • proverbialbunny 8y ago
        Dynamic memory management? What part of C++ do you mean? I'm unfamiliar. Surely not unique_ptr, I would think. C allocates on the heap too, so I must be misunderstanding.