Cost of enum-to-string: C++26 reflection vs. the old ways (opens in new tab)

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 choose the C-macro implementation (which is 30+ years old) over this, every time. Or the good old switch case where I understand what's going on.

I understand that reflection is a powerful capability for C++, but the template-meta-cryptic-insanity is just too much to invite me back to this version of the language.

I was a fool to assume that the same forces shaping the ugliness of C++ syntax would not also be at work in C++ 26.

I find it quite readable. I can understand what it does even though I haven't written reflection code yet myself.

Is it? I'm mostly used to (pre-)C++11 and the only unusual operators I see are ^^T (which I presume accesses the metadata info of T) and [:e:] (which I assume somehow casts the enumerator metadata 'e' to a constant value of T).

And template for but I assume that's like inline for like in zig.

I wish I understood the reason for the `std::define_static_array`... Why can't `std::meta::enumerators_of` just return something that can be iterated through????

You realize c++11 is closer in age to C++98 than C++26?

One obvious answer is that people probably don’t want to write a whole parser and wire up new steps in their build pipeline just to do something simple like get the name of enum cases as a string.

Without taking a stance on whether in-language meta programming facilities are good or bad, it’s not hard to find examples of cases where people find it useful to have them.

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.

Meta programming in C++ can enable you to remove lots of runtime branching in your code at the cost binary size.

Actually why even specify metaprogram as C like source code? It must be convenience. But there is little practical use, like a good program always models a lot of different representations of more or less the same things, just recombined and processed a little differently. Why would we want to deal with semantics of C types for example, if we can model a much clearer and better constrained universe of types used in e.g. a de/serialization framework? Even only pointers are quite special, and often only of very immediate use, but there is no point in e.g. persisting them to disk or sending them over the network.

Why would I write a parser that almost-but-not-quite matches the compiler's own parser, when I could just use the compiler's parser directly? I don't want to write a parser, and I especially don't want to debug weird corner cases where my implementation diverges somehow. I just want to write some code that goes like, for each field in T, do X.

C++ metaprogramming is bad, but the problem there is the C++ part, not the metaprogramming-in-the-language part.

This works for extreme needs.

But you're probably not doing s ton of metaprogramming all the time like you should be, and would with a language that allows it.

The lack of metaprogramming is also why C is so slow compared to C++

Writing a C++ parser is much harder than a C parser to the point there had been just 3 parsers used among all C++ compilers for quite a while. So you'd need to use some library for parsing. So now you are looking into the library's parser compatibility with the compiler you are using (it might not support the C++ standard you are on at all, it can have bugs preventing it from parsing the code that the compiler parses just fine) and not just on your code but on the library headers you include in your code. What are you going to do when cindex/libclang or whatever chokes on a libstdc++ header? You also have the issue with builtin macros: are they are the same in your library parser? Most likely not. Good luck testing all that.

Two-stage compilation is just a bonus on top: you add a sequential dependency in your build graph and if you have enough of these parsing programs you are going to wait till they are all built before your build can go wide.

Absolutely spot on, easier, and way more effective

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.

Nothing that makes it straightforward. Testing via `static_assert` is a good strategy, but it's not debugging. I believe there are some ways of printing custom diagnostics during compilation, but I am not aware of any step-by-step debugging tool that runs at compile-time.

In practice, I haven't really needed to ever debug `consteval` functions -- it's quite easy to get the right behavior down thanks to `static_assert`-based testing and thanks to the fact that they do not depend on external state (simpler).

Keep macro generated code isolated in self-contained wrapper functions that just return a static object corresponding to an argument. Then you can treat them like black boxes that never fail and never need to be stepped over.

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?

Why people are still using debuggers?

I never felt the need for them when doing TDD.

This cost is not significant nowadays, it's the frontend/parsing time.

You can also use `#pragma once` which works everywhere, is nicer, and technically needs less work by the compiler, but compilers have optimized for include guards since a long time ago.

Some random measurements I found: https://github.com/Return-To-The-Roots/s25client/issues/1073

What I found (so far on MSVC) is that #pragma once does only process the file once, where as include guards still open the file each time it is included. Though it takes almost no time to do so but it still appears on the traces.

I'm going to experiment with other compilers and figure out how they handle it.

>...from John Lakos' Large-scale C++ software design from 1997...

I'll just point out that Lakos updated his work with a new edition in 2019:

Large-Scale C++ Volume I: Process and Architecture

and there's scattered evidence that Volume II might be published in Feb. 2027 [1]

Large-Scale C++ Volume II: Design and Implementation

[1]: https://www.amazon.co.uk/Large-Scale-Implementation-Addison-...

I've not been diligently keeping up with C++ recently but there's a C++20 feature called modules. Per Wikipedia, they're somewhat like precompiled headers.

https://en.wikipedia.org/wiki/Modules_(C%2B%2B)

C++ conference speakers (including keynotes) are now begging everyone to stop using enum to string in their example. While they are a simple and easy to understand example, reflection is for much more interesting problems. I can't think of any other example that I would type into a comment box or put on a slide.

I explicitly mentioned that GCC 16.1 was the compiler used in the benchmarking section, do you think I also need to add a disclaimer in the conclusion section as well?

Regardless, I don't think things are going to differ much with Clang. Without PCH/modules, standard header inclusion is still the "slow part" of C++ compilation, regardless of the compiler used and the standard library used (libstdc++ vs libc++). `#include` is fundamentally the same on any modern compiler.

Because the reflection feature itself seems quite fast on GCC (compared to the cost of the header), I predict the results will be similar on Clang as well.

I was thinking the same thing. Modules are still not widely used, it is a reasonable guess that there are a lot of optimization opportunities left.

Or VC++ if ever, which has the best modules support, but it is still trailing behind in C++23.

I'd argue reflection is very much a feature for libraries. You wouldn't use it directly, but your JSON / YAML serialize is then built on top of it. So are your bindings for scripting engines like Lua.

our company doesnt do compile on push on the server. It only does it when approved by a subset of ppl. The reason is we have a limited amount of servers and compile takes about 40min/variation. It's very annoying considering at prev job compile took about 10 min in total (project was organized better+ better servers) and there wasn't a limit at all-> compile at each push to gerrit.

I'm now trying to migrate from msbuild to cmake+sscache+PCH for std libraries while also trimming unnecessary includes to reduce suffering in the future - if not for me then at least for future developers. So I would say compile time is important for development. It causes other limitations too (like bugfixing becomes a huge commit with several squished fixes together to avoid recompiles, messing up git history or slower context switching when developing several features in parallel)

It has a direct impact on the amount of emails and slack messages I get to reply to.

Utter BS. Compilation times matter for productivity, developer motivation, iteration speed, CI turnaround time, and so on.

I'm sure you wouldn't say "it doesn't matter how long it takes to compile" it if took days. So where do you draw the line? Regardless, it matters.

Author here. It isn't a clear "win" at all, there are tradeoffs to each approach.

The downside is, of course, that it's ugly and very awkward to use.

That's the essence of C++: you're basically trading ergonomics for compile times.

Pretty much. Was hoping it would've been a 'reflection slam dunk' but no... same 'ol same 'ol.

That'll never happen. The engine's entire serialization system is built around their custom reflection layer and UHT. Not to mention how this would affect licensees. PLUS, they just laid off a bunch of people, and the leftovers are focused on Tim's Verse fiasco. I hate to use jargon here, but there's no "business value" to switching.

EDIT: and based on these compilation time results, this would be a major setback for building the engine, which already takes an eternity.

In short, it probes enum values in a pre-defined range (e.g. [-256; 256]), and parses the `__PRETTY_FUNCTION__` macro at compile-time to extract the name of the enumerator.

Once you have that in place, you can easily detect duplicates, etc...

Of course, there are major limitations, as it's all a big hack: https://github.com/ZXShady/enchantum/blob/main/docs/limitati...

Similarly interesting is Boost.PFR, which gives you reflection superpowers since C++14: https://github.com/boostorg/pfr

Logging, debugging, auto-generation of UIs/editors, etc... This is an extremely common operation and for a good reason.