4 ms·

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 idea

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.
  - monocasa 8y ago
    Pretty much all heap allocation outside of init time is verboten in embedded contexts, whether C or C++. So yes, the regular unique_ptr, vector, some lambdas that heap allocated their captured, etc. You're not allowed to use malloc in C either. Check out MISRA C, and the JSF C++ Standard for examples of embedded code standards.
stevenhuang 8y ago
Agree with what you said, and that's a very interesting paper--thanks for the link!
aseipp 8y ago
Nobody who uses C++ for embedded development uses or cares about the STL though, and its absence isn't exactly surprising for a number of reasons... The selling point is features like RAII and templates, which can greatly reduce duplication and improve readability. Sure, you technically can't use the STL for whatever reasons, but practically it doesn't actually matter at all, and its absence comes with the territory for everyone involved. Being able to use more of the STL in contexts like this would be nice for future projects, perhaps.
- BenFrantzDale 8y ago
  Keep in mind, the STL isn't limited to the containers, there are tons of algorithms that are very useful for embedded programming that don't throw exceptions, are vetted, and are as efficient as hand-written algorithms.

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.
- monocasa 8y ago
  Pretty much all heap allocation outside of init time is verboten in embedded contexts, whether C or C++. So yes, the regular unique_ptr, vector, some lambdas that heap allocated their captured, etc. You're not allowed to use malloc in C either. Check out MISRA C, and the JSF C++ Standard for examples of embedded code standards.

stevenhuang 8y ago

Agree with what you said, and that's a very interesting paper--thanks for the link!

aseipp 8y ago

Nobody who uses C++ for embedded development uses or cares about the STL though, and its absence isn't exactly surprising for a number of reasons... The selling point is features like RAII and templates, which can greatly reduce duplication and improve readability. Sure, you technically can't use the STL for whatever reasons, but practically it doesn't actually matter at all, and its absence comes with the territory for everyone involved. Being able to use more of the STL in contexts like this would be nice for future projects, perhaps.

BenFrantzDale 8y ago
Keep in mind, the STL isn't limited to the containers, there are tons of algorithms that are very useful for embedded programming that don't throw exceptions, are vetted, and are as efficient as hand-written algorithms.