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.
Reflection for C++26
31–40 of 214 posts
Re: Reflection for C++26
#32I 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
#33Re: Reflection for C++26
#34Earlier 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.
Re: Reflection for C++26
#35Earlier 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…
It's nice to know I can just transition to C++26 to fix this.
Re: Reflection for C++26
#36I 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
#37I 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
#38Earlier 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);…
Re: Reflection for C++26
#39Wow 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”?
Re: Reflection for C++26
#40Wow 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”?