While this is helpful in a way this blog also contains outdated information. Given that in embedded you most of the time build the world and have most of your stuff as source code you should never get stuck on an old compiler unless it is a one-shot project.
And that leads to the ability to use modern C++ methods in places where it is highly useful such as the ability to use "if constexpr" and templates to make your somewhat generic code optimal for a specific usage scenario like writing a templated driver that adapts to the specific hardware variant you are building. This means you can often run without making runtime decisions on hardware situations that cannot ever occur because the specific chip or board does not even have the option.
Also I noticed the virtual interface mentioned and I would express a minor point of caution there for embedded developers. A virtual interface is really meant for dynamic/runtime situations where the object behind the interface can change at runtime. In embedded that is a more rare case. Consider using concepts to define such interfaces and pass the concrete objects as template parameters where it makes sense. I have on several occasions these last four years reduced the binary size overhead of products by doing this as an object accessed through a virtual interface prevents the removal of unused methods from the final binary (they have to be present even with devirtualization happening to reduce the indirection cost).
Also template bloat is real but also a somewhat over-"hyped" problem in embedded. It occurs when the same template is run several times to produce many variations of the same template. In most template programs this will not happen by accident. Mainly avoid making any reoccuring template configuration apart of the type. Instead we now have the option of initializing objects during compile time using constexpr objects. Make your configuration of the object that way (maybe even consteval) and use that in "if constexpr" if possible. All compilers relevant in embedded can manage to put this configuration into the read-only/flash memory and load it in during start-up/boot.
I will be honest mentioning Zephyr in a situation when talking about how outdated the Unix design philosophy is, is a bit funny to me since Zephyr (like ecos kinda did once) tries to be Posix-like in its APIs (but ends up not really improving things over the other embedded OSes TBH).
Apparently according to some ACCU and CPPCon talks by Khalil Estel this can be largely mitigated even in embedded lowering the size cost by orders of magnitude.
Yeah. I unfortunately moved to an APU where code size isn't an issue so I never got the chance to see how well that analysis translated to the work I do.
Provocative talk though, it upends one of the pillars of deeply embedded programming, at least from a size perspective.
Well, it's mostly type definitions and compiler stuff, like type_traits. Although I'm pleasantly surprised that std::tuple is fully supported. It looks like C++26 will bring in a lot more support for freestanding stuff.
No algorithms or containers, which to me is probably 90% of what is most heavily used of the STL.
c++ gets a lot of hate much of it based on past traumas with specific codebases and history of use.
This has built up into a culture where people who have little to no experience with c++ but who have been told and seen only bad headlines about it join in with those who have legitimate concerns, those who are promoting their favorite language and those who are trolls leading to a general mood.
It is almost perfectly predictable that if you open the discussion on a link to a c++ article on this site there will be someone promoting either zip, rust or circle in that discussion. There will also be a comment on the bloat of the language and someone venting their trauma from some horrible code base.
Yeah no switching a group of developers over to some new language is not more efficient. It is a lot of work. And on top of that you will need to add time to either wrap your existing code base or rewrite it with developers who are new to the language they are using. You will have folks who like that and can do it, but you will also have a lot who would have a much harder time with that. Most corporations would legitimately ask what is switching the language gaining us and is it worth it. Now the conclusion might be that it is worth it, but it is equally possible that they decide against it. Never underestimate inertia.
I work on a c++23 embedded platform that is used in very small microprocessors up to embedded linux stuff. We ship stuff that needs to run constant and C was just too unsafe for us (C requires you to remember to call functions RAII saves you from that) so we switched 2 decades ago (before my time there).
C++23 is not abandoning embedded. Instead there is a tonne of misinformation around that is confusing people. You can easily tell what parts of the STD is available by looking up the concept of Freestanding, which is a legitimate part of the c++ standard which tells you what is absolutely safe to use in embedded. Usually some of the non-freestanding stuff is also safe to use.
Then what you do is add support for the ETL (github.com/ETLCPP/) which will help you by offering STD like classes for the parts that are not safe to use or just give you the std class wrapped in their namespace.
What we do is turn off RTTI and for now exceptions (most compilers let you do that with ease but we are looking at maybe using them in the future because of recent research indicating it would be possible and save us binary size at the same time) and you lean heavily into the constexpr side of things because anything you can get the compiler that is running nightly or on your PC to do rather than on the embedded system is just fine. We do not use coroutines so there I have no opinion.
Personally I am looking forward to the Reflection stuff because it is all compile time (and no that does not mean that your std on your pc somehow leaks illegal functions into your code constexpr/consteval is embedded safe) and it will allow me to make code that will be easier to debug than the recursive template expansions are now (stepping through a recursion is bad even if we strictly limit the depth of them but reflection will allow me to do an expansion into a flat set of ifs instead).
Yes, let's everyone look up the "freestanding" concept in N4950 section 16.4.2.5, and take note how it requires both exceptions and RTTI. Is that what you meant by "C++23 is not abandoning embedded"?
Yes, compilers support turning off exceptions and RTTI, for a long time now. C++ language does not. They could have supported it, but have chosen to explicitly not, as seen in the above section from the standard.
Nothing the committee does seem to support embedded. I will be glad to be shown I'm wrong.
You are right. Its not the job of the committee to support anything. They just have to vote on proposals.
Imagine Linux devs would start worrying about what "C standard" wants xD.
In my industry (gamedev), folks never needed to worry about how non-standard our code is either. As long as it ships on relevant half-dozen platforms and gets job done, its fine. One does not get a Boy scout badge for being standard compliant.
In C++ if you’re not standards compliant you are running the risk of hidden UB big time. Maybe your compiler will reveal it to you, probably not. Good luck!
And that leads to the ability to use modern C++ methods in places where it is highly useful such as the ability to use "if constexpr" and templates to make your somewhat generic code optimal for a specific usage scenario like writing a templated driver that adapts to the specific hardware variant you are building. This means you can often run without making runtime decisions on hardware situations that cannot ever occur because the specific chip or board does not even have the option.
Also I noticed the virtual interface mentioned and I would express a minor point of caution there for embedded developers. A virtual interface is really meant for dynamic/runtime situations where the object behind the interface can change at runtime. In embedded that is a more rare case. Consider using concepts to define such interfaces and pass the concrete objects as template parameters where it makes sense. I have on several occasions these last four years reduced the binary size overhead of products by doing this as an object accessed through a virtual interface prevents the removal of unused methods from the final binary (they have to be present even with devirtualization happening to reduce the indirection cost).
Also template bloat is real but also a somewhat over-"hyped" problem in embedded. It occurs when the same template is run several times to produce many variations of the same template. In most template programs this will not happen by accident. Mainly avoid making any reoccuring template configuration apart of the type. Instead we now have the option of initializing objects during compile time using constexpr objects. Make your configuration of the object that way (maybe even consteval) and use that in "if constexpr" if possible. All compilers relevant in embedded can manage to put this configuration into the read-only/flash memory and load it in during start-up/boot.