3 ms·
It's astonishing how involved a fucking modern JSON library becomes. The once "very simple" C++ single-header JSON library by nlohmann is now * 13 years old
by mbac32768 1y ago
It's astonishing how involved a fucking modern JSON library becomes.
The once "very simple" C++ single-header JSON library by nlohmann is now
* 13 years old
* is still actively merging PRs (last one 5 hours ago)
* has 122 __million__ unit tests
Despite all this, it's self-admittedly still not the fastest possible way to parse JSON in C++. For that you might want to look into simdjson.
Don't start your own JSON parser library. Just don't. Yes you can whiteboard one that's 90% good enough in 45 minutes but that last 10% takes ten thousand man hours.
- EasyMark 1y agoYeah I use this and I think most of friends do too :)
- mbac32768 1y agoyeah it seems like every other C++ project uses it
- typpilol 1y ago122 million unit tests? What?
- fHr 1y agoholy shit
- codr7 1y agoYeah, but as long as I'm not releasing in public, I don't need to support 20 different ways of parsing. That's the thing with reinventing wheels, a wheel that fits every possible vehicle and runs well in any possible terrain is very difficult to build. But when you know exactly what you need it's a different story.
- vovavili 1y agoI am very surprised to hear the unit testing statistic. What kind of unholy edge cases would JSON parsing require to make it necessary to cover 122 million variations?
- kstenerud 1y agoThe more speed optimizations you put in, the gnarlier the new edge cases that pop up.
- modeless 1y agoThis may say more about C++ than JSON
- 0x000xca0xfe 1y agoThe best language to handle unusual JSON correctly would probably be Python. It has arbitrary size integers, mpmath for arbitrary precision floats and good Unicode support.
- kstenerud 1y agoI did write one, but I needed to because the already-written data must be recoverable on a crash (to be able to recover partially written files) since this is in a crash reporter - and also the encoder needs to be async-safe. https://github.com/kstenerud/KSCrash/blob/master/Sources/KSCrashRecordingCore/KSJSONCodec.c https://github.com/kstenerud/KSCrash/blob/master/Sources/KSC... And yeah, writing a JSON codec sucks. So I'm in the process of replacing it with a BONJSON codec, which has the same capabilities, is still async-safe and crash resilient, and is 35x faster with less code. https://github.com/kstenerud/ksbonjson/blob/main/library/src/KSBONJSONEncoder.c https://github.com/kstenerud/ksbonjson/blob/main/library/src... https://github.com/kstenerud/ksbonjson/blob/main/library/src/KSBONJSONDecoder.c https://github.com/kstenerud/ksbonjson/blob/main/library/src...
- flohofwoe 1y agoMost people don't need the remaining 10% but value a small and easy to maintain codebase (which nlohmann definitely isn't).
- zelphirkalt 1y agoMany of the problems disappear when performance is not critical, because that opens up the options for many much nicer, much safer, and simpler languages and C/C++, to write a correct parser in.