21 ms·
JSON for Modern C++
- stevekemp 7y agoKudos on the very thorough readme, complete with CMake instructions, most of the time people take it for granted that you know how to embed libraries and dependencies. Writing documentation, and easing users into your project, is an underrated skill.
- einpoklum 7y agoActually, a detailed documentation belongs in a Wiki or a separate markdown document, that README.md is a bit much...
- panpanna 7y agoThe wiki is a GitHub thing and will not be included in your git clone. I personally prefer a doc/ folder with RST files in it. That's what the Linux kernel does.
- frou_dh 7y agoWikis on GitHub are themselves git repos and can be cloned separately: https://help.github.com/en/articles/adding-or-editing-wiki-pages#cloning-wikis-to-your-computer https://help.github.com/en/articles/adding-or-editing-wiki-p...
- rienbdj 7y agoThe fact that instructions are even required shows how poor the state of c++ packaging is.
- dasloop 7y agoNo, is not. The instructions are for users of the lib that are not using a package manager. If you are using one, in my case vcpkg, then no special instructions are required.
- amirmasoudabdol 7y agoThis is a solid project and I’m using it in many different projects for years. The developer team is responsive and care about the quality of the project as well as people’s need. I can not recommend it enough.
- ryandrake 7y agoYea, I replaced cJSON with this library last year on one of my personal projects and never looked back. Good library. I came to this thread thinking, "Oh, did someone find something nicer than nlohmann json? Now I'm going to have to take some time to investigate it!" Turns out it's the one I've been using.
- wodenokoto 7y ago> In languages such as Python, JSON feels like a first class data type. Is that because the python dictionary happens to looks so much like json, or what do they mean?
- gsaga 7y agoYeah, that's probably what they meant.
- masklinn 7y agoYes, though more the other way around: part of json's appeal (on purpose) is that it covers the core subtypes of most dynamically typed programming languages (strings, number, booleans, arrays and maps), so moving data to and from json is straightforward and convenient.
- falsedan 7y agoI lost my mind at this sentence. If feels like a first-class data type because the result of parsing is one of the built-in data types (which can be round-tripped to a similar JSON string). And as soon as you care about serialisation of types it starts feeling incredibly clunky.
- Thorentis 7y agoYeah exactly. The equivalent would be to have a JSON parser in C++ which turns a JSON file/object into a C++ object that is accessed in similar ways to other typical C++ objects. So: {"key": value"} becomes json->key = "value" rather than json["key"]. In this library I feel as if they've used operator overloading to emulate the way JSON is used in other languages, rather than making the JSON feel like a first class C++ citizen so to speak.
- Merg 7y agoI think as far as other languages are concerned, the best JSON handling gives youn Serde in Rust and F#, from what I read. If only C++ metaprogramming was easier without crazy complexity, Json library would be made to be much smaller and more efficient with less work.
- mirsadm 7y agoI have been using json11 for a few years now (https://github.com/dropbox/json11 https://github.com/dropbox/json11). It looks like it has been abandoned though. This seems like a great alternative.
- roryrjb 7y agoI 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.
- nurettin 7y agoPeople are biased towards github repos with recent commits in github as opposed to projects that are stabilized and frozen. This is a loss considering the man-hours spent on creating a stable library.
- amelius 7y agoStill 13 open issues though. Most of them are marked as enhancement, but 3 as bugs.
- einpoklum 7y agoHow does this compare with RapidJSON, JSONCpp and JSON Spirit - other popular C++ JSON parser libraries? Links: http://rapidjson.org/ http://rapidjson.org/ https://github.com/Tencent/rapidjson https://github.com/Tencent/rapidjson https://github.com/open-source-parsers/jsoncpp https://github.com/open-source-parsers/jsoncpp https://www.codeproject.com/Articles/20027/JSON-Spirit-A-C-JSON-Parser-Generator-Implemented https://www.codeproject.com/Articles/20027/JSON-Spirit-A-C-J...
- Kh4L 7y agoWe 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/ http://cocodataset.org/ metadata files and RapidJson is 100% faster.
- e12e 7y ago> 100% faster. So, twice as fast - it parses the dataset in half the time?
- doublerebel 7y agoRapidJson is very efficient. I have used several JSON libraries for C++, and right now I'm really enjoying json_dto, which is built on RapidJson. It has great developer UX, including the most succint syntax I've used, and support for std::optional. https://github.com/Stiffstream/json_dto https://github.com/Stiffstream/json_dto
- Kh4L 7y agoOn 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
- vips7L 7y agoDoes anyone write C++ and not care about performance?
- Teknoman117 7y agoMy only mild complaint with this particular JSON library is that it's fairly easy to shoot yourself in the foot with the compile times if you don't explicitly ensure that you use the json_fwd.hpp header in your headers.
- umvi 7y agoCould you elaborate on how to speed up compile times? We use this library extensively and I've never heard of "json_fwd.hpp" until now.
- kyberias 7y agoI 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.
- jstimpfle 7y agoI tried to suppress the urge to release my frustration, but seeing that the only slightly critical comment in this thread is the downvoted one let me forget my good intentions. WTF. 10s of thousands of line of code, > 10K lines in include files (yay compile times!) for a task that should be only a side concern and should be straightforward to implement. JSON has how many? 2? data types, and writing super efficient parser primitives for it must be easily possible to do in <1K lines of implementation and <50 lines of headers. If there are special requirements in performance or type safety / structural integrity, JSON is far from the ideal choice. And even if one is required to use it under such circumstances due to political issues (in which case, sorry), that doesn't mean that all the other >99% of applications call for a massively oversized library like this. (Update, upon closer inspection I'm not even sure that speed is the main concern of this library. It really looks like it tries hard to be "Modern C++" by implementing all sorts of compile time insanity, bells and whistles (which will never fit 100% with clients and will be impossible to adapt)).
- Betelgeuse90 7y agoRecently had a discussion with a colleague about JSON in C++. It's actually a big issue, because reflection isn't really supported in C++. It's not just a blocker for parsing objects as JSON, it's a fundamental limitation for being able to map objects to any kind of format in a general fashion without creating initializers for every object. I actually have no idea what kind of black magic they're doing to achieve this, but it sounds pretty admirable to me.
- cocoa19 7y agoWhy do you need reflection for a message format that requires objects (use hash map) and lists (array or linked list).
- jchw 7y agoNote that this library basically requires exceptions to be enabled, which may or may not be the case in your environment. (It is actually possible to use without, but then exceptions become aborts, and you have to dance around that.)
- omouse 7y agoI'm wondering what the difference between this and json-cpp https://github.com/open-source-parsers/jsoncpp https://github.com/open-source-parsers/jsoncpp is. They look like they provide the same functionality, albeit this looks more "modern C++ style"?
- boblivion 7y agoFor starters nlohmann/json is fuzzed (look at the test directory). From my experience it is really stable. jsoncpp still has some quirks as it relies on unit tests only. Big no no for me.
- omouse 7y agoFuzzed? That's a rarity in tests, that's awesome!
- umvi 7y agonlohmann's is super nice. You can set a json object equal to a map or vector and it will automatically understand and do it. I doubt you can do that with jsoncpp.
- baltbalt 7y agoI don't understand those single header libraries. Anyone writing code in c or c++ knows how to link a library. It's really annoying when writing code for a platform with limited ram.
- umvi 7y agoUnfortunately template-heavy libraries have to be header-only; otherwise the preprocessor doesn't know which flavors of the template you want to use.
- pretty_colors 7y agoGource for this repo: https://youtu.be/cyaCZDffAbQ https://youtu.be/cyaCZDffAbQ
- Kenji 7y agoYou know it's a hipster repo when there are emojis in the commit messages. Also, header-only libraries suck for compile times. Need to be abstracted with impl-pimpl idiom to compile in a sane amount of time again. No thanks.
- etaioinshrdlu 7y agoI used this library on bare metal arduino a year ago. It felt funny doing high level programming on such crappy hardware!
- de_watcher 7y agoWe just use the good old Qt JSON parser/generator. It's basic and has no compilation speed issues.
- psyclobe 7y agoIts a great library however 99% of its 'wow' moment can now be easily replicated with a few meta checks and can be adapted to basically any 3rd party json system.