[HN Gopher] Reflection for C++26
___________________________________________________________________
Reflection for C++26
Author : svlasov
Score : 40 points
Date : 2024-06-30 11:26 UTC (1 days ago)
(HTM) web link (isocpp.org)
(TXT) w3m dump (isocpp.org)
| pjmlp wrote:
| Note that there are links pointing to examples on Compiler
| Explorer, using the EDG and clang preview implementations.
| a_e_k wrote:
| 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 also see this for
| benchmarking and testing frameworks to automatically find the
| workloads and tests in a non-hacky way.)
|
| I also wonder about how this feature interacts with translation
| units (or modules) and linkage, though. I'm reminded of the
| static initialization order fiasco; this seems like it might
| open up issues that make that look tame by comparison.
| Dwedit wrote:
| Compile time or runtime? Compile time reflection would be
| completely painless and bloat-free.
| armchairhacker wrote:
| Compile-time ("static reflection")
| shortrounddev2 wrote:
| RTTI is a super vital feature for deserializing without having
| to generate code or write a ton of tedious boilerplate. I'd be
| very happy with RTTI in C++ and my life would be instantly
| easier if there were RTTI in typescript so I didn't have to use
| any of the hacky solutions out there for deserializing JSON on
| backends without RTTI.
|
| I suppose C++'s template system might be able to generate JSON
| deserializers with static reflection as well
| chongli wrote:
| 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.
| fooker wrote:
| 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.
| comex wrote:
| > I suppose C++'s template system might be able to generate
| JSON deserializers with static reflection as well
|
| It definitely can, and it will be faster and more type-safe
| than doing it at runtime. But if you do want to do it at
| runtime, well, it's possible to implement runtime reflection
| as a library on top of compile-time reflection, so someone
| will probably do that.
| thechao wrote:
| 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 reflection
| system is very clever, i.e., exposes enough information to the
| linker to strip duplicate-ish symbols, you end up with a bunch
| of reflection copies.
| bingo3131 wrote:
| FYI: this is the latest draft of the proposal and it has not been
| voted into C++26 yet, but it is getting close.
| steveklabnik wrote:
| https://github.com/cplusplus/papers/issues/1668#issuecomment...
|
| Looks like it did very well in St. Louis!
| TillE wrote:
| Finally. I think there have been proposals since C++17 at least,
| and all I really wanted is for them to solve the common problem
| of basic static reflection for enums (without hacks like
| magic_enum uses).
| jjmarr wrote:
| magic_enum is killing my build time with endless template
| instantiations. Is this going to be faster?
| leni536 wrote:
| 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 around with that. I did not try it yet.
| flykespice wrote:
| Has finally the committee come to _reflection_ after decades of
| standard revisions and footguns? /j
| stefanos82 wrote:
| 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?
| adamnemecek wrote:
| Serialization comes to mind.
| quotemstr wrote:
| > 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
| jcranmer wrote:
| The main canonical use case for static reflection is
| serialization, where serialize<T>() 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 provide.
|
| Does static reflection simplify such cases? ... Outlook
| unclear. It's definitely gnarlier to actually write the
| serialize() method, and in many cases, it does feel like a
| better option is to write a specific domain-specific language
| to specify what you want to specify, with a tool to operate on
| it as appropriate (think something like protobufs for
| serialization).
| ahartmetz wrote:
| This looks surprisingly fine! The opaque, extensible types remind
| me of Win32 with its extensibility through ever new message
| types. The syntax looks better than expected, too - well, it's
| better than templates...
___________________________________________________________________
(page generated 2024-07-01 23:00 UTC)