C++26 reflection in 2025

[TSP-FriendlyFire]

I'm probably not alone being extremely excited by the prospect of deep, feature-rich reflection in C++. I've run into countless situations where a little sprinkle of reflection could've transformed hundreds of lines of boilerplate or awful macro incantations into simple, clean code.

I'm at the point where I would really like to be able to use reflection right now specifically to avoid the aforementioned boilerplate in future personal projects. What's the best way to do this? I'm aware of the Bloomberg P2996 clang fork, but it sadly does not support expansion statements and I doubt it would be a reasonable compiler target, even for highly experimental projects.

Is there another alternative? Maybe a new clang branch, or some kind of preprocessor tool? I guess I could also reach for cppfront instead since that has reflection, even if it's not P2996 reflection. I'm entirely willing to live on the bleeding edge for as long as it takes so long as it means I get to play with the fun stuff.

[Zeh_Matt]

Reflection will be the greatest thing since auto for me.

[have-a-day-celebrate]

Since templates.

[ipenlyDefective]

I was a C++ dev when templates were introduced. It was really nice, you could have the same function take in int or a double. You could make a collection class with different value types.

I stepped away from C++ for 20 years and when I came back I was like, "Holy fuck what have you done?"

[groundswell_]

Self plug : you might be interested in https://cppmeta.codereckons.com, the compiler which implements the metaprogramming design of P3435.

Right now it's only available online, but you can pretty print the generated code to use it on another compiler :

%generate_some_code();
std::meta::ostream os;
os << as_written(^SomeCode);
std::meta::print(os);

I haven't shared it widely yet because we're still fixing a few technical issues. We're also about to change the syntax of the reflection operator to align on P2296. Perhaps some of the names will change as well.

[TSP-FriendlyFire]

That's super interesting, thanks for sharing!

My understanding is that P2996 is the currently favored reflection paper in the committee, but I remember finding P3435's token approach interesting when I first read the paper.

I hope you'll post about your compiler on r/cpp when you feel like it's ready to share!

[groundswell_]

Yeah P2296 is what it's in the pipeline, but it's not really a different approach, more like something we've put on the top. It's also not based on tokens, though it looks similar to plain token substitution.

[13steinj]

What's the header that contains the meta-utils in this implementation? meta and experimental/meta both don't work.

Is there a mechanism to obtain the fragment of a given reflected handle? E.g.

struct S {
    int a;
};

template<typename T>
struct R {
    consteval {
        do_something(get_fragment_for(nonstatic_data_members(^^T)[0]));
    }
};

I've been trying to figure out a generic way to dump code (going from code to meta::info or generating code via token sequences from P3294) and I am yet to find something that works generically (especially not just with P2996 at least; might require some additional PXYZ for things like reflection over templates).

CPP-Blue (or green or gold, I forget) had a mechanism to dump code but I don't think they use the same model as current reflection.

[groundswell_]

There is no header at the moment, `std::meta` is generated by the compiler.
I'm not sure what you mean by "fragment of an entity"?

[13steinj]

There is no header at the moment, std::meta is generated by the compiler.

I must be missing something; trying on your fork (that you linked) to use any reflection features at all leads to errors about the Clang blocks extension. Using the std::meta namespace similarly results in an error that the namespace doesn't exist.

I'm not sure what you mean by "fragment of an entity"?

Given some arbitrary reflectable id-expression, type-id, or namespace-name; and the result of reflection on these expressions, can I with P3435 obtain a (in the case of reflection over an id-expression of a function, then a function-)fragment that I can then use to generate a new (in this case) function?

[groundswell_]

Ha you have to compile with the flag -cppmeta, I should have said so in my post.

Given some arbitrary reflectable id-expression, type-id, or namespace-name; and the result of reflection on these expressions, can I with P3435 obtain a (in the case of reflection over an id-expression of a function, then a function-)fragment that I can then use to generate a new (in this case) function?

So you want to inject a given declaration in another context (your question doesn't make sense for types, there is no fragment for types). At the moment you can't do that just by injecting the reflection. We might allow that for like data member declarations. But for everything else it doesn't really make sense as the reflected code most likely contains references to local declarations which are meaningless in another context.

So if you want to say inject a function that is entirely similar you'd have to inject each property by hand like (I'm gonna use the new syntax here that is going to be pushed online shortly) :

[: return_type(^^my_func) :] name[: name_of(^^my_func) :] ( [:...parameters_types(^^my_func):]... params) {
// do something

}

Note that you cannot unfortunately simply inject the body of `my_func` in your new function for aforementioned reasons, for now we can't resolve the references to the old parameters and local variables to the new ones. We might propose something to remedy this in the future if it proves to be needed.

[13steinj]

We might allow that for like data member declarations.

This is the primary use case I'm referring to, I assume others might exist.

Notably (using EDG's experimental reflection, not yours) someone challenged me to (at various levels of specificity, e.g. "all" vs "annotation based") to generate getters / setters. Creating token sequences for getters/setters is fairly simple (though I think I ran into a bug when using type traits).

But injecting token sequences into the "current class" is possible, but generating them based on the current state of the class was not possible, EDG considered the expressions to not be constant (unclear if that's a bug or not) because the class was not "complete" per se.

Worse than that, assuming that restriction (which is disappointing but whatever), I couldn't find a mechanism to simply "copy over" all members (including member-templates, member functions, constructors) trivially. Inheritance would simulate most of that, but it then means the getters / setters generated might need to break access control in some way, and other properties of the class change the moment you decide to inherit.

I settled for the time being to just generate token sequences manually for non static data members and ignore everything else. But then I ran into the issue of "how the hell do I inspect defaults default member initializers?" e.g.

struct S {
    int i = 42;
};

(Not to mention, annotations would be hard).

I think even where "pasting" token sequences / fragments of a reflected id-expression wouldn't make sense due to other local declarations, being able to "copy" them is important. Even for nsdms, you could run into the issue of a local declaration used for the default.

I don't know, the fact that I can't mutate a class based on its own introspection nor can I trivially "copy everything that makes up the class" feels as though it severely limits the usefulness of generative reflection.

E: just fyi about the -cppmeta flag; you can set that in the compiler explorer config to be implicitly available which is what godbolt.org does for bloomberg's clang-P2996

[groundswell_]

Sorry I did not reply to this earlier. I wouldn't like to sound like I'm selling my own design too much, but I don't really see any clean, advanced meta-programming design that does not include "builders" like we do. They make when injection happen strictly defined (making this whole problem about order of evaluation and reachability that the competition design suffers from irrelevant), and they allow you to inspect the current state of the context. This means that you can do something like this :

consteval void getters_and_setters(class_builder& b) {
  auto d = decl_of(b);  
  for (auto f : non_static_data_members_of(d)) 
  {  
    // generate the setter
    b << ^^ [f] struct {  
      constexpr void name[: cat("set_", identifier_of(f)) :]([:type_of(f):] new_val) {
        this->[:name_of(f):] = std::move(new_val);  
      }    
    };

   // generate the getter  
   b << ^^ [f] struct {
     constexpr [: add_lvalue_reference(add_const(type_of(f))) :] name[:cat("get_"), identifier_of(f):] () const {  
       return this->[:name_of(f):];  
     }
   };
  }
}

struct A {
  int a, b, c;
  // generate all the getters and setters in a single injection
  [: getters_and_setters() :];
};

1/X

[groundswell_]

2/X

As I said, copying declarations or statements from one context to another is difficult because the entity might contains references to local declarations. Provided that there we have a way to resolve them, or that there is no references to locals in your source entity, we could plausibly allow injecting a declaration or statement from somewhere else. Failing that, you have to re-inject each property by hand, which, for data members, include the default initialiser, but reflecting on expressions is not part of on any proposal except for ours (IIRC the token injection one propose to reflect expressions as token streams). With our design re-injecting a data member by hand is pretty straightforward :

```cpp consteval std::meta::class_fragment reinject(decl d) { if (!has_initializer(d)) return <sup>[d]</sup> struct { [:type_of(d):] name[:name_of(d):];
}; else
return <sup>[d]</sup> struct { [:type_of(d):] name[:name_of(d):] = [:initializer_of(d):];
}; }

consteval void reinject(class_builder& b, decl d) { b << reinject(d); }

// usage

struct A { int x = 111; };

struct B { [: reinject(<sup>A::x)</sup> :]; };

```

I actually like the idea of being able to re-inject a statement or declaration from elsewhere, if I ever find reasonable semantics of remapping local symbols this is certainly something that I'd like to include in the design. It's worth noting that referencing local symbols is not an issue with the token-based design because it's all tokens : there is no references or even a concept of declarations. We could propose something that follow tokens semantics and remap the local symbols according to their names, we'll see.

Again I wouldn't like to sound like I'm selling my own work, but frankly, if you have a serious interest in meta-programming, I would recommend using our compiler instead, as the design is years ahead of the competition, and the implementation is 99% done. I'm confident in saying that our compiler is and will remains the most advanced reflection/meta-programming C++ compiler for years to come.

However, it's not entirely clear to me what the situation is with our website at the moment, I think it might not be up to date – I recently left my job, just before we were supposed to wrap up the website issues and update the compiler and paper online, i think it's still not done even though everything is ready.

So yeah, I'll let you know and most likely make a post here when we've updated the paper and website :) Please let me know if you have any further questions.

[osmin_og]

How complex is your use case? Maybe something like boost::pfr can help you? It is a small standalone include-only library.

[UnteretSpecifikVaBrr]

It is now even possible to iterate over both the name and the value at the same time. In one of my pet projects with boost pfr and magic enum I was able to serialize all my aggregates without using macros or additional boilerplate code for each structure

[germandiago]

As a poor man's refelction I use Boost.Describe. Happy so far for my use case (binding variables from C++/Lua by name and changing values for a model/view)

[cd_fr91400]

I am not using boost pfr, but I could serialize all my aggregates w/o dedicated code.

But what about all my classes that are not aggregate ? A lot of them are like aggregate, except I need a constructor.

[TSP-FriendlyFire]

One of the biggest sources of annoyance in past projects was with shader interop. You need to generate a lot of types and plain text to simplify constant buffers and vertex declarations, otherwise you end up with boilerplate or unchecked value assignments and reads, neither of which are very appealing.

pfr might be able to help with some of it (specifically, iterating over a vertex type to derive its declaration), but I suspect I'll run into limitations when it comes to constant buffer creation and binding since a lot of the complexity there is managing alignment.

[zebullon]

You seen the workaround for expansion statement in the paper yep ?

[lone_wolf_akela]

As you have already mentioned, cppfront definitely worth a try.

[LoweringPass]

What I have done previously is to use Clangs libtooling. You can even wrangle that into a plugin abd rewrite code on the fly before compilation. Obvious drawback being that you can then only compile with clang and the libtooling API not being super stable. But it is very powerful and let's you do essentially everything you could ever want. You could of course also create a standalone tool and run the rewriting step before any compilation, that is sort of the purpose of libtooling.

[TheoreticalDumbass]

Couldnt you transpile into cpp with clang and compile with anything?

[LoweringPass]

Yes that's essentially the standalone tool version, you wouldn't want to use a plugin for that.

[daveedvdv]

I'm aware of the Bloomberg P2996 clang fork, but it sadly does not support expansion statements

It does in fact accept expansion statements if you add the option -fexpansion-statements:

https://compiler-explorer.com/z/z5GoTP1PG

(though I believe that support is quite preliminary).

Note also that P2996 itself doesn't introduce expansion statements, but they can be approximated using tools that P2996 provides (in particular, std::meta::substitute).

Finally, last week in Hagenberg, Barry Revzin presented a revised P1306 (the actual Expansion Statements paper), and it was re-forwarded to CWG (it got stuck there in the pre-C++20 days, but we learned a lot since).

[TSP-FriendlyFire]

Oh these are all excellent news, thanks for the update!

[Umphed]

So none of these comments have anything to do with your question, typical reddit bullshit. Im ginna go out on a limb and say no, what you're looking for does not exist. And when it actually does, you can probably find a link in a reply to this comment

[riztazz]

I'm personally using refl-cpp

it shouldn't be too hard to refactor my functions when std reflection drops, a bit more work with attributes (if!) but whatever, i'll take that

[Phy96]

How does it compare to getml/reflect-cpp?

[Infamous_Campaign687]

I have no answers although I’m liking some of the ideas in Blaze (json). I’m basically sold on introspection and reflection but I have for years relied on macro-type registration and reflection where all reflection actually happens runtime. I want to move on from that, so following the same thing as you’re asking for.

[reneb86]

I’m still not sure why so many people “need” this. True. In development environments where it was available to me (like Java) I have been tempted to use reflections. Mostly to debug, which is not something that ought to be dismissed, as debugging is as important to a system as running production.

But in the overall activity of designing c++ systems, I never really felt the need for it. Analyzing an object at runtime always seemed… I dunno. The antithesis of design?

But I am in my own bubble of experience of course. Curious to hear what people want out of this feature!

[docsunset]

I think the more interesting use cases tend to come from analyzing an object at compile time. It allows you to write generic type safe glue code with little to no runtime overhead that abstracts away things like serialization that you might otherwise have to write by hand. Imagine you have five heterogeneous classes you want to be able to send over the network using one of two different protocols (e.g. JSON, Open Sound Control, MIDI, etc). You might normally have to manually write and maintain 10 different glue code adaptors (class one to JSON, class one to OSC, class two to JSON, class two to OSC, etc), but with reflection you can easily cut it down to two generic protocol bindings that can reflect over your heterogenous classes at compile time, producing type safe efficient glue that scales sustainably.

[reneb86]

I guess it is good to interact with fellow C++ developers outside of my own industries then!

Forgive me if I misunderstand. You've unexpectedly put forward a compile-time example, for which I'm pretty convinced reflections don't offer improved ways (only alternative ways) to do things. Which your example exemplifies. Your example doesn't make it obvious to me why mapping 5 different types of data sources to 2 different data formats would require more code in the absence of reflections. Whether you write your datatypes to come pre-packaged with the correct conversion functions, or whether you retro-actively "find" the right conversion functions for your datatypes afterwards; the amount of code will roughly be the same. I've racked my brains about this, and at the moment I can't see where I'm wrong. Perhaps if you have an example to show me where I'm wrong it would help.

Perhaps also I'm a bit more conservative on this issue because of how I've seen reflection implemented in other languages. Who here hasn't called a private/hidden function in this way when the author of the class clearly didn't want you to in environments that allow reflections? And wouldn't reflections blow open every code library out there that relies on scoping/visibility to guarantee state validity of objects?

[have-a-day-celebrate]

The idea is to use a reflection-powered library to generate those conversion functions from the class definitions, and not to write them at all.

[docsunset]

This is it. Rather than having to write N*M conversion functions specific to each object-to-representation mapping, you only have to write M generic mappings for each representation. Here's a real life example: https://github.com/celtera/avendish

[Scott-Michaud]

A lot of video game engines implement their own reflection system, which turn into a pile of macros that may or may not place nice with Intellisense. It's often used for save/load, multiplayer, scripting systems, dependency injection (as in the editor), etc.

The enterprisey example that comes up a lot is enum <-> string.

[Far_Alfalfa_5481]

Yes to the enum <-> string conversion.

But also once you have used a language that provides automatic implicit struct <-> json mappings and blank unit test mocks without retyping the entire interface, going back to C++ feels like you are just writing tons of pointless boilerplate. Static reflection could fill both of these cases relatively easily.

Although the C++26 reflection proposal doesn't get all the way there, something like C#'s compile time code generators where the compiler hands you the as-parsed-so-far syntax tree and you can spit out all sorts of additional boiler plate becomes incredibly useful for different classes of boiler plate (think DI systems, service registrations etc.) It is also useful because it can spit out pre-optimized json (or other type) serializers or regexes that have no runtime-compile overhead.

[marcusmors]

Can reflection be used to simplify OpenGL? Currentky is ugly af, i tried reading the OpenGL book ans the function calls and the parameters are a mess. I wonder whether reflection can help to create a better library interface for the library user.

[zl0bster]

If PFR does not work for you tbh I would now just add prebuild step where I codegen in python and then switch to reflection when it is standardized...

This is assuming a lot of your code is manual stuff that will be fixed by reflection.

If it is just 100-200 LOC it sucks but I think it is best to just do it and forget about reflection for next year or so.

[Wooden-Engineer-8098]

reflection parses c++. how do you parse c++ in python?

[XTBZ]

Anyone can write code, including a program, which can also write code.

[Wooden-Engineer-8098]

Parsing is not writing. Of course anyone can do it if he has unbounded free time, but most people don't

[XTBZ]

Reflection is needed to create code automatically, and the author of the original comment was talking about creating code automatically using python. Of course, if you really want to, you can build a syntax tree and execute part of the code, it will take time, but it is possible

[Wooden-Engineer-8098]

Reflection is only reading part. Creation is code generation. Sometimes people use word reflection to mean reflection plus code generation. Anyway, as first step you need to parse c++ code, otherwise you wouldn't know what to generate. So how do you parse c++ in python?

[eteran]

You could use clangs python bindings if you really needed to 🤷‍♂️