←back to thread

196 points svlasov | 2 comments | | HN request time: 0.034s | source
Show context
stefanos82 ◴[] No.40851614[source]
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?
replies(8): >>40851661 #>>40851675 #>>40851709 #>>40851795 #>>40851942 #>>40852552 #>>40853159 #>>40853615 #
bdd8f1df777b ◴[] No.40853159[source]
What I commonly need is JSON serialization/parsing directly with structs.
replies(1): >>40853788 #
beached_whale ◴[] No.40853788[source]
They exist, for instance https://github.com/beached/daw_json_link , uses mappings of JSON <-> class members/construction. It handles a bunch of types out of the box and allows custom types to be mapped. Also, it integrates with some of the reflection like libraries out there now(Boost.Describe/Boost.PFR) and will be trivial to add C++26 static reflection when available.

Because the library doesn’t need to allocate unless the underlying types being parsed to do, it has been constexpr since C++17 too.

A bunch of people have used libraries that use macros for reflection like or PFR to integrate other C++ JSON Libraries too.

replies(1): >>40862169 #
1. bdd8f1df777b ◴[] No.40862169{3}[source]
Without static reflection, we need to write a lot of boilerplate code, and those boilerplate is not guaranteed to stay in sync with the struct definition. That is why static reflection is sorely needed.
replies(1): >>40862991 #
2. beached_whale ◴[] No.40862991[source]
Even static reflection isn’t a panacea and we have it now the libraries like PFR that give us a reference and name of each member for aggregates. But this is the same problem for anything else using those types too. For non-aggregates we need reflection or some manual library.

I am not disagreeing, just more saying what we have now.