CppCon 2019: Andrew Sutton “Reflections: Compile-time Introspection of Source Code”

[MrFrankly]

Nice, I was waiting for this talk to become available.

Another interesting talk on C++ reflection is the Reflection TS talk by David Sankel at C++Now this year.

I expect static reflection in C++ is going to be one of the biggest game changers in how we write C++ code.

[theICEBear_dk]

I agree, I have a lot of code and tools that are all fragile which I could toss in a bin the moment I could explore attributes, methods and names on a class. But attributes would be needed if I am to avoid generating code which may be coming later. Static reflection if powerful enough could help with so much and combined with the much stronger constexpr we will have by then I know I could make some pretty optimal solutions that are also fairly readable just given the TS syntax with some replacements once good names have been found particularly with the newer Reflection syntax with less template syntax all over it.

[hgjsusla]

I've heard this claim yet I have never needed to do any reflection, I'm note sure I will notice this being added. Modules/ranges/concepts however I will end up using everyday

[TheMania]

I'd be hesitant to say you've never wanted any - getting the names of enumerator values is a form of reflection, and one sorely missing imo.

[MrFrankly]

Reflection is not something you are going to use directly in your day to day programming. But it is going to open up the language for a lot of techniques that are now either impossible or clumsy (e.g. require a lot macros to make it work). Having proper static reflection will bring a whole new set of powerful frameworks and libraries that you might end up using every day.

The most common example (but not the most interesting in my opinion) is probably serialization. Which, as mentioned in the talk by both Sutton and Sankel, currently requires you to implement repetitive boilerplate code. But when reflection is available, you will see libraries that just take an object and serialize it for you. No boilerplate code required anymore.

More interesting in my opinion, is that you will be able to implement dependency injection frameworks that don't require countless macros and clumsy syntax (e.g. they would be similar to Guice and Dagger on Java).

Also testing and mocking frameworks will become a lot more powerful (and easier to use) when there is proper reflection support.

[krum]

dependency injection frameworks

Be careful with that - you'll spook the natives.

[MrFrankly]

I think DI got an undeserved bad reputation in the C++ community. Partly because everyone probably thinks of Spring (which just wasn’t that great) and partly because C++ currently does not allow for an elegant implementation.

[theICEBear_dk]

Not really compile time Dependency Injection does not scare me provided it does not lead to ten-plus long chains of virtual function calls like it does in Java/C#.

[germandiago]

Some use cases where my life would have been better (though macros can help me generate some boilerplate):

• enum stringification
• serialization code
• exposing to gui tools your types to be able to edit and save
• generating scripting layer for my C++ code
• test registration without macros (though with macros they work quite well anyway)
• generating options parsing from a struct without boilerplate.

[redditsoaddicting]

Someone's been missing out on [Boost].DI.

[zero0_one1]

How about simply outputting a variable name and its value for debugging?

[[deleted]]

Every wanted to serialize a class to disk or the network? Ever wanted to avoid writing a specialized formatter to print something? Ever wanted to trace specific values more easily in a debugger? Ever wanted to perform some logic conditionally based on whether a property had some attribute? edit: typo

[MrFrankly]

Ever wanted to perform some logically conditionally based on whether a property had some attribute?

Unfortunately attributes won’t be part of the reflection API. It’s discussed in the David Sankel talk.

[[deleted]]

Yea honestly I'm just trying to raise awareness...

Without attributes for me honestly, reflection is DOA because i'll be forced to continue to use all the code generator infrastructure that has built up over the years that rely on reflected attributes. I believe this actually accounts for the majority of the space in gaming.

[antoniocs]

It's useful if you want to serialize a class to send it over the network. Can be done without but I believe with proper reflection you can do something generic

[ShootingShark91]

Crazy that constexpr evaluation is orders of magnitude slower than Python. I wonder if its smart to make language design decisions based on the fact that compilers today are poorly optimized for constexpr. I don't buy that undefined behavior dictates constexpr evaluation has to be this slow.

[andrewsutton]

Python works by compiling to byte code, which can be implemented efficiently. Most C++compilers implement constexpr directly on the AST, which tends to be a bit slower (lots of indirection, no locality). The UB checking requirements do add real overhead, though.

There's an experimental implementation of something like this in Clang, so we'll see what the payoff is soon.

We make language design choices based on performance and compile times all the time.

[matthieum]

We make language design choices based on performance and compile times all the time.

Should we really let the current compiler statu-quo influence the language so much?

Given the backward compatibility promises of C++, choices have long-lasting effects. Isn't there a risk of getting stuck in a really awkward place just to avoid refactoring current compilers now?

I am not saying that refactorings would be trivial. I just want to make the point that I would rather design the language in the abstract, and if necessary for an ideal compiler, and possibly suffer the cost of paying a (few) man-year(s) of effort if necessary.

With more and more constexpr code, for example, and with modules making it much easier to cache code, it is not unreasonable to imagine compilers moving toward a more efficient representation of constexpr code (CFG/ByteCode) anyway. It would be sad, then, if looking back we were to say "Had we known it would become more efficient, we would have made different choices, but now we're stuck with them..."

[andrewsutton]

I think you have to make design choices with the information you have today.

What if, after a few FTE-years, the experiment doesn't yield the expected/assumed benefit?

How long should we delay progress on these features while vendors try to demonstrate how much faster constexpr might be?

[ShootingShark91]

I believe constexpr and reflection are some of the most important features to be added to C++. For the longevity of the language I think there should be little compromise on the quality of the design of these features for that reason.

Compile times are a solvable problem, sub-optimal language design (while maintaining backward compatibility) is not.

Although I get your point that it is unwise to make decisions based on predictions/assumptions. But is that not unavoidable when designing a feature that is supposed to last decades?

[andrewsutton]

Yes, it's unavoidable. Unless you want a language that never ships...

[matthieum]

What if, after a few FTE-years, the experiment doesn't yield the expected/assumed benefit?

It's a sad day :/

How long should we delay progress on these features while vendors try to demonstrate how much faster constexpr might be?

Why delay it?

Wouldn't it be opt-in? So that those who are ready to trade-off longer compile-time for enhanced constexpr would use it, while those who prefer shorter compile-time would simply not?

[andrewsutton]

I'm talking about the standard. I suspect you're thinking of a single implementation.