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 (the meta program is just normal C), infinite capabilities - can nest this to arbitritary depths, need meta-meta programming? Make a program that generates a meta program.
For example, what does https://miguelmartin.com/blog/nim2-review#implementing-a-sim... look like with C++26's std::meta::info?
My guess is: libclang is more suited for this situation if you care about compile times, even if Python is used.
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.
Seeing this argumentation is so tiresome, because it feels like there is a lack of self-awareness regarding what is "familiar" and what isn't, which is subconsciously translated to "ugly" and "bad".
In a lot of languages, you achieve the same with 1 line of code. It's not about familiarity, it's about the fact that it's a long and convoluted incantation to get the name of an enum.
Why do I have to be familiar with all those weird symbols just to do a trivial thing ?
Update:
Zig:
const Color = enum { red, green, blue };
const name = @tagName(Color.red); // "red"
Rust:
#[derive(Display)]
enum Color { Red, Green, Blue }
let name = Color::Red.to_string(); // "Red"
Clojure:
(name :red) => "red"
enum Color { red, green, blue };
auto name = to_enum_string(Color::Red); // "Red"You won't have to care about ^^ and [:X:] if you just want to consume reflection-based utils, which was the whole point of my comment.
And template for but I assume that's like inline for like in zig.
Not familiar with Zig but AFAICT `inline for` is about instructing the compiler to unroll the loop, whereas `template for` means it can be evaluated at compile time and each loop iteration can have a different type for the iteration variable. It's a bit crazy but necessary for reflection to work usefully in the way the language sets it up.
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.
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).
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.
I never felt the need for them when doing TDD.
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.
Promises and claims have been made for longer than that on how Modules would have improved compilation times and made everyone's lives easier. In 2026, I still have to see any real evidence of that, especially when PCH + unity builds are much easier to use (except on damn Bazel, which supports neither) and deliver great results.
If after 6+ years of development Modules are still so far behind, it is fair to question if the problem is with the design/implementability of the feature itself.
It would be cool if the stated goal of C++29 was compile times.
For many useful use cases, you don't need C++26 reflection at all. E.g. https://www.linkedin.com/posts/vittorioromeo_cpp-gamedev-ref...
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.
struct MyStruct {
int val = 42;
string name = "my name";
};
{
"val": 42, // if JSON had integers, and comments of course
"name": "my name",
}
(The link above shows ImGui generation, but the same exact logic can be applied for serialiation to JSON/YAML/whatever.)
> The magic sauce? Boost.PFR! An incredibly clever library that enables reflections on aggregates, even in C++17.
That's not vanilla C++!
That is if you are worried about doing this by hand reflection is not the answer, something like protobuf where your data structures are generated is the answer.
Almost all the Java web frameworks are giant balls of reflection. Name a function the right way or add the right magic annotation and the framework will autowire it correctly.
It's a pretty powerful tool. (IDK if C++'s reflection is as capable, but this is what was enabled by java's reflection).
I find this to be very powerful, and also very unintuitive/undiscoverable at the same time.
Most frameworks in Java are very similar. The ones that aren't are effectively doing what "expressjs" does in terms of setup, which is still pretty discoverable.
Most java frameworks rely on annotations rather than naming schemes which makes everything a lot easier to grok.
C++ build times are hard pill to swallow when migrating from c. This is just another reason we'll probably stick to writing c as t the company where I work. It's like asking someone to give up instant compilation for cleaner easier to read apps?
Also now that we have cleanup handlers in c (destructors) even less of a reason to move...
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
We've come full circle huh?
Why do you need this, logging? In that case I would rather reflect the logging statement to pribt any variable name, or hell, just write out the string.
If saving for db, maybe store as string, there's more incentive for an enum in the db, if that's a string you might as well. At any rate it doesn't seem a great idea to depend on a variable name, imagine changing a variable name and stuff breaks.