81–90 of 214 posts
Earlier quoted context omitted.
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
Earlier quoted context omitted.
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
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…
Even Go is rediscovering that staying simple just doesn't happen for any language that gets industry adoption at scale.
Earlier quoted context omitted.
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++.
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…
I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/tools people.
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…
Since the proposals target problems with differing philosophies, they each have different traps in them from bad time complexity to outright unrefined behavior. Keeping up with the updates hard because of this.
I think many C++ projects are (or will be) basically infeasible to maintain not because of the old problems but due to the exploding complexity of the interactions of all features, unless developers actively ban using large parts of the language.
More specifically, with this I can iterate over struct members and get their names and types, but I cannot attach additional information to these members, like whether they should be serialized or under which name.
The referenced proposal P1887R1 covers this, but that's not included here, right?
P1887R1: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18...
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…
Indeed I wish they were even more aggressive about breaking changes
Rust is nifty but there is simply too much existing C/C++ out there and "rewrite it in Rust" is not a serious suggestion
Maybe one day we have some cool AI that magically rewrites old C/C++ automatically, but by then I also assume we will have AI-designed languages
Until then, we need C/C++ to be maintained and modernized because we are actually running the world with these languages