Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflection for C++26

isocpp.org

Post reply on HN
Print view View original

71–80 of 214 posts

Re: Reflection for C++26

#71

Post by petters »

jcranmer wrote: post #18
stefanos82 wrote: post #14

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?

The main canonical use case for static reflection is serialization, where serialize () can easily have a default case of calling serialize() on each of the fields. In the more general case, you basically want to have some library method that does something based on the structure of a struct or class, without having to define some sort of explicit, intrusive interface that said struct or class implementation has to pr…

Serialisation often needs additional information not present in the struct definition: for enabling backwards-compatibility and default values.

Same for command line parameters. We want documentation strings, maybe dashes in the name etc.

But that can surely be solved with a little more advanced struct

Re: Reflection for C++26

#72

Post by flohofwoe »

gpderetta wrote: post #32
a1o wrote: post #31

Earlier quoted context omitted.

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.

That doesn't mean much unfortunately, Clang had a fully working C99 designated initialization in C++ for many years, but the designated initialization that ended up in C++20 is only a butchered version of the full feature set despite Clang clearly demonstrating that it's possible to integrate the full C99 designated init feature set into C++.

Re: Reflection for C++26

#73

Post by [deleted] »

qalmakka wrote: post #66

While I love this paper and this proposal in general, as a C++ developer every time C++ adds a new major feature I get somewhat worried about two things: 1. how immense the language has become, and how hard it got to learn and implement 2. how "modernising" C++ gives developers less incentives to convince management to switch to safer languages While I like C++ and how crazy powerful it is, I also must admit decades…

[deleted]

Re: Reflection for C++26

#74

Post by physicsguy »

CuriousCosmic wrote: post #41
stiglitz wrote: post #28

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 that really care found workarounds

Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.

Re: Reflection for C++26

#75

Post by Aardwolf »

fluoridation wrote: post #38
greenavocado wrote: post #29

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?

Ouch, I first thought this was the example of how to do these things _before_ reflection is introduced to C++

The for loop required to do enum to string really makes it

Re: Reflection for C++26

#76

Post by z_open »

forrestthewoods wrote: post #69

I'm surprised at the positive response in this thread. I find the syntax of this beyond atrocious! My goodness C++ really does not know how to do anything simply does it?

Many C++ features are useless outside of writing libraries, but your typical developer is going to be forced to understand how they work at some point. The result is just a burden.

Re: Reflection for C++26

#77

Post by coopierez »

j16sdiz wrote: post #51
fluoridation wrote: post #38

Earlier quoted context omitted.

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.

Thankfully it is so easy to quickly import libraries into C++...

Re: Reflection for C++26

#78

Post by tsimionescu »

greenavocado wrote: post #26
stefanos82 wrote: post #14

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?

Any sort of reflection brings C++ one step closer to Python. Implementing serialization for complex types often requires manual code writing or external tools. With static reflection you could automate this process template void serialize(const T& obj, std::ostream& os) { for_each(reflect(T), [&](auto member) { os Simplified property systems class Person { public: Person(const std::string& name, int age) : name(name)…

Note that you should really be using std:print rather than std::cout if using modern C++.

Re: Reflection for C++26

#79

Post by _flux »

sankhao wrote: post #65
quotemstr wrote: post #17

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 doable in c++20 https://github.com/stephenberry/glaze

That's pretty neat! What's the C++20 feature that enables this?

Re: Reflection for C++26

#80

Post by pjmlp »

a_e_k wrote: post #13
pjmlp wrote: post #2

Note that there are links pointing to examples on Compiler Explorer, using the EDG and clang preview implementations.

Yes, that's a clever way of demonstrating viability (and with more than one compiler implementation). I do like the examples that I see there. This seems like the kind of language feature that I might not make much use of directly in general application code, but would wrap up in utility functions or use via lower-level libraries that the application code builds on. E.g., they showed command-line parsing, but I could…

I am a big defender that the only way to fix many of the mistakes that ended up in the standard is to adopt the same policy as other languages, papers without preview implementations shouldn't be accepted.

There are still a few gotchas being ironed out, there was a talk at ACCU about many corner cases.

Post reply on HN