Alt text:
A screenshot from the linked article titled “Reflection in C++26”, showing reflection as one of the bullet points listed in the “Core Language” section
A screenshot from the linked article titled “Reflection in C++26”, showing reflection as one of the bullet points listed in the “Core Language” section
It’s pretty cool when you use it right but it’s also really easy to shoot yourself in the foot with, even by C++ standards. For example, in other languages (I’m coming from Java/C# which both have it) it lets you access private/protected fields and methods when you normally wouldn’t be able to.
There’s also a noticeable performance penalty over large lists because you’re searching for the field with a string instead of directly accessing it.
For the times it is necessary (usually serialization-adjacent or dynamic filtering/sorting in a table) to use reflection, it’s faster at runtime than converting an object to a dictionary/hashmap. However, 99% of time it’s a bad call.
If you look at the proposal, this is specifically “static reflection”, i.e. compile-time reflection. So it doesn’t actually have any of the downsides you mention, as far as I can tell.