Yeah I remember doing that in one project. And then at least I found c++ and ATL back when it came out. I never went back to doing COM in C after that.
I mean a readable implementation of tuple with minimal overhead is a great case for me (went from around 1.6k lines to approximately 250 lines). I wrote an implementation including the normally difficult to implement tuple_cat based on c++26 within a few hours.
My favorite thing is that I will get to remove and replace most of the cryptic template recursion stuff I have with "template for" and maybe a bit of reflection. Debugging the unrolled stuff will be a joy in comparison.
The answer is being debated at the moment in c++ papers and building on experience from other languages with extensive compile time evaluators like D. One thing that is happening is that we will get compile time exceptions (a paper for that is aiming to add this to the language in c++29 has come out) which may help us in reporting problems. Which will be important as there is also a lot of papers and talk about an extension of reflection allowing for better output generation which as far as I know was deferred until reflection had been accepted.
But there is also good news that with the advent of JIT like components for compile time evaluation in progress and the like of CLion having the beginnings of a compile debugger in combination with concepts there is a chance some help is available and on the way.
However right now you have to rely on compiler errors and static_asserts which is not ideal of course.
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.
reply