Live data from Hacker News

Reflection for C++26

isocpp.org

31–40 of 214 posts

Re: Reflection for C++26

#31

I have been waiting for static reflection for the last 20 years. The current proposal seems quite nice, but the real question is whether any non trivial usage will kill compilation performance.

The implementation that exists for clang is fast but we will see how it goes with MSVC and GCC.

Re: Reflection for C++26

#32
post #31

I have been waiting for static reflection for the last 20 years. The current proposal seems quite nice, but the real question is whether any non trivial usage will kill compilation performance.

The implementation that exists for clang is fast but we will see how it goes with MSVC and GCC.

At least is a proof existence that it can be done.

Re: Reflection for C++26

#33
I haven't touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn't Qt's moc implement some of this stuff because it wasn't available in C++? Could this replace moc?

Re: Reflection for C++26

#34
post #10
post #8

Earlier quoted context omitted.

You don't need RTTI to deserialize data in a clean way. What you need is return-type polymorphism. Haskell has this and it makes writing serializers and deserializers symmetric and totally painless.

Return type polymorphism and inheritance doesn't mix very well. Swift got into this mess early in it's lifecycle and it's type checking is still more expensive than the rest of the compiler combined, and unpredictable on top of that.

C++ has both return type polymorphism and inheritance. What it doesn't have is the kind of type inference that Haskell has. Its type inference is very limited.

Re: Reflection for C++26

#35
post #21
post #11

Earlier quoted context omitted.

magic_enum is killing my build time with endless template instantiations. Is this going to be faster?

magic_enum works by walking all possible enumeration values from one-by-one in a wide range at compile time, instantiating a function template for each one so it can extract the __PRETTY_FUNCTION__ name, which is very slow. The C++26 feature just directly returns the vector of the named enumerators in one go, so it should be way faster. They have a reference implementation on godbolt under clang, so you can play arou…

Wow. I'm trying to make some of these template instantiations explicit on a large project I'm on as magic_enum is one of the largest contributors to our build-time.

It's nice to know I can just transition to C++26 to fix this.

Re: Reflection for C++26

#36

I haven't touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn't Qt's moc implement some of this stuff because it wasn't available in C++? Could this replace moc?

Qt has straight-up dynamic reflection. You can get pointers to functions from strings, and such. This is just static reflections (which is still very useful!), so it's not a complete replacement. Even if it was, I would Qt would replace its build system.

Re: Reflection for C++26

#37

I haven't touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn't Qt's moc implement some of this stuff because it wasn't available in C++? Could this replace moc?

moc can be replaced without reflection: https://woboq.com/blog/verdigris-qt-without-moc.html

Re: Reflection for C++26

#38

Earlier quoted context omitted.

Here are some examples from the linked paper * Converting enum values to strings, and vice versa * Parsing command line arguments from a struct definition (like Rust's clap) * Simple definition of tuple and variant types, without the complex metaprogramming tricks currently used * Automatic conversion between struct-of-arrays and array-of-structs form * A "universal formatter" that can print any struct with all its f…

Converting enum values to strings, and vice versa enum class Color { Red, Green, Blue }; template std::string enum_to_string(E value) { constexpr auto enum_info = reflect(E); for (const auto& enumerator : enum_info.enumerators()) { if (enumerator.value() == value) { return std::string(enumerator.name()); } } return "Unknown"; } template E string_to_enum(const std::string& str) { constexpr auto enum_info = reflect(E);…

This is terrible. You can't just do Enum::Member.str or something?

Re: Reflection for C++26

#39

Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it. Looking at the examples ( https://isocpp.org/files/papers/P2996R4.html#examples ) what really stands out is the…

By ”stagnation” do you mean “not getting new features”?

[deleted]

Re: Reflection for C++26

#40

Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it. Looking at the examples ( https://isocpp.org/files/papers/P2996R4.html#examples ) what really stands out is the…

By ”stagnation” do you mean “not getting new features”?

N3340 is from 2011. Prior to c++11 they had failed to deliver major changes to the language. And arguably the disfunction is still there where big ideas get destroyed in committee (reflection) or take forever and come out half-baked (modules).
Post reply on HN