daw_json_link VS Better Enums

They might have good luck with https://github.com/beached/daw_json_link it has support for stuff like JSON lines and alike plus other ways that only use as much ram as their underlying data structures do as it parses directly to the user DS. Plus it has an iterator/range interface for things like arrays if needed.

We will add more benchmarks in the future, but for now you can see the comparison of daw_json_link with rapidjson. glaze is faster than daw_json_link, which is over twice as fast as rapidjson.

I am biased, but prefer https://github.com/beached/daw_json_link Super fast and you work with your native data structures without the overhead of DOM parsing/lookup

You can also look into https://github.com/beached/daw_json_link which claims to support nullable values in the readme.

The library I author does this. https://github.com/beached/daw_json_link . It's fast, GB/s too, and provides the mapping mechanism, iteration types, json lines support, event based parser, along with a non-owning json_value for when the mappings don't fit right or if one is querying. Pretty much everything but an owning JSON value as it's not something I've ever needed more than temporarily and brings a lot of complexity that is solved by using the actual C++ data structures one is eventually parsing into anyways.

So DAW JSON Link does have a DOM view, however it does not have a owning view. The json_value(even supports JSON Path in a limited form) type and json_raw mappings can help here. But there is no hard line between parsing view the json_value and the mappings to concrete data structures. One can mix and match.

Is this the repo? Never saw it linked in our convo, and I’d like to give it a whirl.

daw_json_link is what you're looking for : https://github.com/beached/daw_json_link

Check out https://github.com/beached/daw_json_link , it provides a non-typeerased way to parse JSON straight into user-defined data structures.

I really like better_enums instead of magic_enums. There’s no limit on enum size with it: http://aantron.github.io/better-enums/

It was heavily used at a former employer of mine, so definitely a solid production-ready solution.

IIRC I then switched to another library doing the same stuff: https://github.com/aantron/better-enums It is not as magical, as it uses a special macro to define the enum, using dedicated syntax. So it only works for enums you yourself define. However, it did work a lot better for me with enums with huge values.

I can't keep up! First we have better enum, then some guy at a conference says we have to use wise enum instead, and now you speak of magic enum!

If you need a laugh today, look at Better Enums library for C++. If you thought moving from C to C++ would let you leave macros behind, think again! Enums in C++ still suck (a bit less than in C though), so someone built a library to help with that. And it's built on macros. So you can only have 64 entries per enum. And the library's code is barely readable.