I feel like the main problem people have with C++ is not the lack of features, but the absolute glut of slightly bad features. That's why I prefer D over C++ in any case: it's a much smaller language. You can learn enough to be dangerous in an afternoon, and enough to be proficient in a week or two.
I on the contrary, I rather reach out to C++, even though I like D, it isn't the features, it is the ecosystem.
Otherwise I rather stay in JVM/CLR/V8 land, when I don't need to.
I have been around D since Andrei Alexandrescu's book was published, even he is now back in C++ at NVidia, as his main work after he kind of stepped away from his role in D development.
And he is one of the figures on C++26 reflection papers.
Oh C++ has the clear advantage in libraries available, for sure. That's not really due to the languages themselves though I'd say. I'm honestly not quite sure why C++ got widely adopted and D did not.
Almost two decades predating it, and sadly no OS vendor picked up on it.
Many people forget C++ is a C sibling, born at AT&T on the same building UNIX and C were being handled, thus it was quite an easy win for C compiler vendors, to add C++ support to their toolchains.
Note that Objective-C also never made it outside NeXT, GNUStep was never that good clone, and had it not been for Apple's acquision and success, maybe we would no longer speak about it.
When Facebook or Remedy Games played with D, we hoped it would somehow improve adoption, that was never the case, and both companies no longer use D.
I find the article very interesting and informative but, honestly, of all of the approaches, I find the basic switch to be the most readable and likely the most maintainable, at least for this case.
The two major problems in C++, we as a comunity suffer from, are those that still insist using it as plain old C with some improvments, and those that do some kind of post-avant guard code, only understood by anyone coding every day in C++, that have as pastime reading ISO standard and compiler reference manuals, while attending C++ conferences.
One keeps the whole security discussion going on, while the other keeps an image that C++ is a language not worth learning.
The limitation with the runtime switch is that it cannot be generated. If all you want to do is have different behavior for each type, then it's probably fine. But if you want to write generic code (apply the same function regardless of type), you need to be able to generate the function using metaprogramming techniques.
C++ isn't great for for metaprogramming, because much of it is a hack that uses the type system to do things it was never originally designed to do (i.e. as a lisp). But as metaprogramming has become more commonplace, the language has evolved with features that make it easier and more readable. It's still all based on a hack, and there's still no good way to debug a metaprogram. But at least I don't have to read the loki book anymore to grok it.
I still prefer to use a proper code generator when I can (it compiles faster, and I can see the generated code). Generating an ordinary switch outside of C++ is certainly an option and is something I've done. But I don't reach for it every time, because those tools tend to be kludgy as well (they can generate invalid C++, which templates and comstexpr cannot).
In D, you can just do a static foreach over a sequence to generate case labels:
https://d.godbolt.org/z/PxWEW14K1
Unfortunely like many things D, eventually C++ gets the feature, even if not as nice to use.
That is template for as part of the C++26 reflection work.
https://isocpp.org/files/papers/P2996R4.html
You will also find some well known names here,
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p34...
I feel like the main problem people have with C++ is not the lack of features, but the absolute glut of slightly bad features. That's why I prefer D over C++ in any case: it's a much smaller language. You can learn enough to be dangerous in an afternoon, and enough to be proficient in a week or two.
I on the contrary, I rather reach out to C++, even though I like D, it isn't the features, it is the ecosystem.
Otherwise I rather stay in JVM/CLR/V8 land, when I don't need to.
I have been around D since Andrei Alexandrescu's book was published, even he is now back in C++ at NVidia, as his main work after he kind of stepped away from his role in D development.
And he is one of the figures on C++26 reflection papers.
Oh C++ has the clear advantage in libraries available, for sure. That's not really due to the languages themselves though I'd say. I'm honestly not quite sure why C++ got widely adopted and D did not.
Almost two decades predating it, and sadly no OS vendor picked up on it.
Many people forget C++ is a C sibling, born at AT&T on the same building UNIX and C were being handled, thus it was quite an easy win for C compiler vendors, to add C++ support to their toolchains.
Note that Objective-C also never made it outside NeXT, GNUStep was never that good clone, and had it not been for Apple's acquision and success, maybe we would no longer speak about it.
When Facebook or Remedy Games played with D, we hoped it would somehow improve adoption, that was never the case, and both companies no longer use D.
I find the article very interesting and informative but, honestly, of all of the approaches, I find the basic switch to be the most readable and likely the most maintainable, at least for this case.
The two major problems in C++, we as a comunity suffer from, are those that still insist using it as plain old C with some improvments, and those that do some kind of post-avant guard code, only understood by anyone coding every day in C++, that have as pastime reading ISO standard and compiler reference manuals, while attending C++ conferences.
One keeps the whole security discussion going on, while the other keeps an image that C++ is a language not worth learning.
The limitation with the runtime switch is that it cannot be generated. If all you want to do is have different behavior for each type, then it's probably fine. But if you want to write generic code (apply the same function regardless of type), you need to be able to generate the function using metaprogramming techniques.
C++ isn't great for for metaprogramming, because much of it is a hack that uses the type system to do things it was never originally designed to do (i.e. as a lisp). But as metaprogramming has become more commonplace, the language has evolved with features that make it easier and more readable. It's still all based on a hack, and there's still no good way to debug a metaprogram. But at least I don't have to read the loki book anymore to grok it.
I still prefer to use a proper code generator when I can (it compiles faster, and I can see the generated code). Generating an ordinary switch outside of C++ is certainly an option and is something I've done. But I don't reach for it every time, because those tools tend to be kludgy as well (they can generate invalid C++, which templates and comstexpr cannot).
Funny enough, the runtime switch, for all practical reasons, is probably just as fast