Its misleading to call it "cost". In the C++ world only runtime cost matters. If using reflection allows to generate faster result code, it doesn't matter how long it takes to compile.
Cost of enum-to-string: C++26 reflection vs. the old ways
121–130 of 189 posts
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#122Never quite understood why people are so obsessed with meta programming capabilities in a language, be it templates, comptime, macros, whatever. I program mostly in C, if I need 'meta' programming I just write another C program that processes C source code (I've written a simple C parser), then in my build script I build in two stages, build meta program, run it, build rest of program. Simple, effective, debuggable (…
C++ has templates, which means, that some meta-code generation needs to be executed for arbitrary types. Doing so with an external tool is impossible.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#123Its misleading to call it "cost". In the C++ world only runtime cost matters. If using reflection allows to generate faster result code, it doesn't matter how long it takes to compile.
It has a direct impact on the amount of emails and slack messages I get to reply to.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#124Earlier quoted context omitted.
C is not slow compared to C++, that is a strange myth.
In practice, C means you end up with generic data structures with pointers to what they contain, rather than being inline. You do see a lot of macro use to deal with this, but that is just primitive, non-typesafe metaprogramming, and it gets unwieldy enough that in practice, you see people add an extra pointer. This is why it gets slower.
In practice, I see people write very performance C code where it matters, while moving on quickly where it does not. C++ code is often highly templated with annoying compile times, but still often slow because it still does not use the right data structures, and the amount of instruction bloat by specializing everything does not help for anything which is not a toy benchmark.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#125Earlier quoted context omitted.
I was very curious to see what C++ 26 brings to the table, since I haven't used C++ in a while. When I saw the 'no boilerplate' example, the very first thought that came to my mind: This is the ugliest, most cryptic and confusing piece of code I've ever seen. Calling this 'no boilerplate' is an insult to the word 'boilerplate'. Yeah, I can parse it for a minute or two and I mostly get it. But if given the choice, I'd…
As a developer who doesn't really write C++ code I'm inclined to agree, but I think Herb Sutter's "syntax 2" project might provide a nice way out of that mess eventually. I played around with cppfront over Christmas and it was a lot more ergonomic than my distant memories of C++11, which I don't even have negative memories of per se. [0] https://github.com/hsutter/cppfront
That isn't going anywhere official.
It is no different from any other language that compiles via C or C++ code generation, it got sold a bit differently due to his former position at WG21.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#126Earlier quoted context omitted.
The parent comment is quite clear: > Why do I have to be familiar with all those weird symbols just to do a trivial thing ? And my answer demonstrates that you do not have to.
> And my answer demonstrates that you do not have to Then again - "where does that `to_enum_string` come from exactly?".
A library that you install via vcpkg or conan.
How many libraries do you read the source code after installing them with the package manager?
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#127Earlier quoted context omitted.
It works generally, but not with expansion statements. See section 3.2 here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p13... It seems that this is being worked on, and eventually the `define_static_array` won't be needed anymore
Just another example where C++ language features are incompatible with each other, to be fixed "in a later version" which may or may not happen. There are so many of those in C++. I desperately wish they'd just do it properly initially.
Me too, unfortunately the old guard sees no value in implementation before standardisation for each single feature.
So it is as it is, plenty of software in C++ isn't going to be rewriten into something else.
Maybe someone can do a Claude rewrite from LLVM into something else. /s
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#128Earlier quoted context omitted.
I mean it's still C++ that's compiled and executed, surely the compiler would be able to provide a way to hook into that?
I don't recall the source, but I don't believe most (any?) c++ compilers implement compile-time code evaluation by compiling and running code. For one thing they are required to disallow all undefined behavior for compile time execution, and some forms of UB only occur when the code is run.
Basically nowadays they ship an interpreter in the box as well.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#129I've been wondering about debug-ability of code using reflection. X-Macros are quite annoying to step through in most debuggers, though possible. While the code in the first example is evaluated fully at compile-time, how would you approach debugging it?
Why people are still using debuggers? I never felt the need for them when doing TDD.
[dead]
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#130I think the conclusion section should indicate that they are based entirely on GCC 16's behavior and current implementation. We should avoid generalizing one compiler's behavior and performance. Curious how this same test would behave once clang ships C++26 reflection.
Or VC++ if ever, which has the best modules support, but it is still trailing behind in C++23.