Live data from Hacker News

Reflection for C++26

isocpp.org

51–60 of 214 posts

Re: Reflection for C++26

#51

Earlier quoted context omitted.

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?

This is how C++ language usually works. Just some primitive for building libraries on. Expect some library change come later.

Re: Reflection for C++26

#52

Can I ask a naive question that consists of two parts and please don't flame me? lol * What type of problems static reflection could solve, in general? * Are there specific cases and / or situations where static reflection could resolve such case, even simplify an unnecessary complexity?

What I commonly need is JSON serialization/parsing directly with structs.

Re: Reflection for C++26

#53

Earlier quoted context omitted.

> What type of problems static reflection could solve, in general? Imagine making a plain struct Point { float x; float y; }; and wanting to serialize it to JSON without further ceremony

This is the thing that's driving me away from C++ very quickly. A big part of our code base is code that handles this, and it either has to be in a DSL and constantly recompiled or we have to make a bunch of boilerplate. It's a huge problem for the language not to be able to do this.

I suggest you to take a look at Boost.Describe.

I have a scripting layer in a game that needs to set properties in a C++ Model. I used a single Boost.Describe macro per struct and a generic get/set property. It worked very well and made me get rid of a lot of boilerplate.

https://www.boost.org/doc/libs/develop/libs/describe/doc/htm...

Re: Reflection for C++26

#54

Earlier quoted context omitted.

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?

Of course not. We must involve 10 layers of templates that mere mortals cannot read and compilers cannot process in reasonable time so the academics at the committee will be happy.

Addressing real problems with simple solutions isn't allowed.

Re: Reflection for C++26

#55

Earlier quoted context omitted.

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

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy. So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and kee…

The people complaining and the people asking for features need not be overlapping sets.

Re: Reflection for C++26

#56

Earlier quoted context omitted.

This is the thing that's driving me away from C++ very quickly. A big part of our code base is code that handles this, and it either has to be in a DSL and constantly recompiled or we have to make a bunch of boilerplate. It's a huge problem for the language not to be able to do this.

Serialization is largely a Solved Problem in modern C++ thanks to template metaprogramming. Wrangling a kludge DSL instead of Serialize betrays poor lang knowledge...

One could argue that template metaprogramming is a kludge DSL of its own.

Re: Reflection for C++26

#57
post #34
post #10

Earlier quoted context omitted.

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.

You can't have two functions that differ in just the return type in C++

Re: Reflection for C++26

#58
post #19

Earlier quoted context omitted.

Having implemented reflection in languages like C(++), before, it is most certainly not bloat-free. There are sorts of 'obvious' things programmers do (like enum-reflection) that end up injecting strings all over the place. The overhead is (worst case) proportional to the source-code size, in those cases. In other cases, you end up with bloat proportional to heavily-utilized template libraries. However, unless the re…

I always thought it’s good practice in C/C++ to have only one translation unit in release builds e.g. SQLite amalgamations, instead of relying on LTO. It also speeds up compilation because it isn’t recompiling the same header files over and over again.

It's a cute idea but just not scalable. It doesn't speed up compilation because separate translation units can be compiled independently and cached.

Re: Reflection for C++26

#59

Can I ask a naive question that consists of two parts and please don't flame me? lol * What type of problems static reflection could solve, in general? * Are there specific cases and / or situations where static reflection could resolve such case, even simplify an unnecessary complexity?

Maybe this doesn't count as static, but I used to regularly use reflection in C# to generate code for interacting with foreign DLLs.

This was a video game mod, essentially. I needed to create a text interface to modify settings for any other mod that might be installed. Other mods would simply implement a settings class with certain attributes, then I could list out all fields and their types. The list was processed into a sort of tree presented through the chat interface. From there I can generate code to modify that settings class from outside its assembly and raise value change events.

The reflection part of that was extremely simple, but just because that's how C# works. C# makes a task like this almost trivial.

At my current job, we have a similar thing. Classes decorated with attributes. We inspect them and check the generic type they implement. This way we register message handlers by their message type dynamically. You write a handler class and it simply works.

Windows Forms had a PropertyGrid control which did the same thing as my text interface, but with a grid of properties you can edit freely.

Most of this stuff is typically done at runtime. But you could have it be static if you wanted. A precious job did this to access the backing array inside of a List object. I offer no explanation or excuse for that one.

Post reply on HN