21–30 of 125 posts
How does this compare with RapidJSON, JSONCpp and JSON Spirit - other popular C++ JSON parser libraries? Links: http://rapidjson.org/ https://github.com/Tencent/rapidjson https://github.com/open-source-parsers/jsoncpp https://www.codeproject.com/Articles/20027/JSON-Spirit-A-C-J...
On the other hand, nlohmann/json has a cleaner and more Python-like API, so if you don't care about performance that much, I'd say it's the way to go
I have been using json11 for a few years now ( https://github.com/dropbox/json11 ). It looks like it has been abandoned though. This seems like a great alternative.
I wouldn't say abandoned, it states in the README: Maintenance note: This repo is stable but no longer actively maintained. No further development is planned, and no new feature PRs will be merged. Bug fixes may be merged on a volunteer basis. With JSON being an unchanging spec this makes sense.
How does this compare with RapidJSON, JSONCpp and JSON Spirit - other popular C++ JSON parser libraries? Links: http://rapidjson.org/ https://github.com/Tencent/rapidjson https://github.com/open-source-parsers/jsoncpp https://www.codeproject.com/Articles/20027/JSON-Spirit-A-C-J...
We used to use. We first micro-benchmarked all those and we found that Tencent/rapidjson was more than 100% faster than nlohmann/json :) Our primary use is to parse http://cocodataset.org/ metadata files and RapidJson is 100% faster.
So, twice as fast - it parses the dataset in half the time?
Earlier quoted context omitted.
On the other hand, nlohmann/json has a cleaner and more Python-like API, so if you don't care about performance that much, I'd say it's the way to go
Does anyone write C++ and not care about performance?
Earlier quoted context omitted.
On the other hand, nlohmann/json has a cleaner and more Python-like API, so if you don't care about performance that much, I'd say it's the way to go
Does anyone write C++ and not care about performance?
Previously we used rapid json which is faster but the syntax of the nlohmann json is nicer and it is much quicker to develop with.. we also use python a lot so the familiarity between the 2 is also useful, some of the other C++ json libs can have quite convoluted api’s for dealing with values, objects and arrays.
Earlier quoted context omitted.
On the other hand, nlohmann/json has a cleaner and more Python-like API, so if you don't care about performance that much, I'd say it's the way to go
Does anyone write C++ and not care about performance?
The overwhelming majority of our IO is reading / writing data files, but those are stored in an optimized binary format. The configuration / metadata accounts for a much smaller fraction of IO. For this tiny fraction we care about flexibility and readability, a slow JSON parser is fine.
Earlier quoted context omitted.
On the other hand, nlohmann/json has a cleaner and more Python-like API, so if you don't care about performance that much, I'd say it's the way to go
Does anyone write C++ and not care about performance?
I don't understand the JSON obsession. JSON as any other file format should be a small detail in any application and require very little plumbing code. In every application, any dependency to JSON should be minimized, contained and preferably eliminated.
Earlier quoted context omitted.
On the other hand, nlohmann/json has a cleaner and more Python-like API, so if you don't care about performance that much, I'd say it's the way to go
Does anyone write C++ and not care about performance?
If reading/writing is the hot path things are different, though.
(It is actually possible to use without, but then exceptions become aborts, and you have to dance around that.)