JSON for Modern C++

[kyberias]

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.

[jstimpfle]

I 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)).

[mrlala]

I can tell this is a C++ thread, heaven forbid you touch anything new within the last 20 years...

The JSON obsession is that everything under the moon supports it- and it's a nice easy structure which can be converted to a dynamic or statically typed object with no issues. Plus it's very human readable, so it's great for debugging.

If you sit there and ONLY use C++, ok why bother? But many systems need to talk to different systems these days. I can setup a webapi that can communicate with my angular typescript, C#, matlab all through nice easy JSON. Each language just converts it to the object and I'm good to go.

The question is why are you so against such a widely accepted format of communication?

[jarjoura]

Developers obsess about JSON for a simple reason, JSON works natively with Javascript. If you have a backend service written in C++, then communicating over JSON is easily consumed by nodejs and the browser.

Of course there are other data transport protocols, XML and ProtoBuf to name a couple off the top of my head, but those are extremely heavyweight.

If you want to use JSON for config files, again, they are easy to make human readable and parse. Grab an off the shelf parser and support whatever scenario users may need. Sure we have yaml and ini, or whatever key=value config format your project creates, but you'll be much more on your own with how deep you want to support various value types.

As far as your complaint or desire for JSON to be minimized or eliminated as a philosophy, I'm not sure why this is the top comment about a very well made and loved C++ library to parse JSON. Are you hoping your comment will change people's minds about what library to use or whether their system needs JSON at all? I don't really understand your goal.

[umvi]

Well I work on embedded systems that have embedded webservers (think your router's webpage). And what data format is easiest to work with when dealing with webpages and browsers? JSON.

Hence, our embedded C++ backend can now easily accommodate and return JSON to the front end using this library.

Plus, what data format do you propose for things like configuration files, etc? No matter what format you choose, you are going to need a parser of that format for C/C++.

[devwastaken]

Json is easier for humans to read and modify, and it's more straightforward to work with in languages like python where you don't have to declare types. Json c++ implimentation is large probably because of trying to provide one library that does all the dynamic things json can do, but in a static language. It also has to be safe to parse, so there's that.

[StreamBright]

Yes but JSON what everybody knows. I have seen a presentation about a not too small company where the engineer explained how much hurdle is to have JSON everywhere in their big data platform. I asked him why they do not use something like Avro instead. He just gave me this weird look like I am asking something extremely stupid and could not come up with any reason. Some engineers just have no idea of the alternatives or the pros and cons of chosing different file/message formats.

[jcelerier]

> In every application, any dependency to JSON should be minimized, contained and preferably eliminated.

how do you suggest interaction with $standardised_protocol which uses JSON in that case ?

[omouse]

Yep this is why I like JSON Cpp, there's a single-file build and I've had success using it with Repl.it: https://neverfriday.com/2013/07/26/learning-jsoncpp/

Since JSON only has basic data types, it's easy to just parse and retrieve objects, similar to using XML tree parsing libraries back in the day.

[rurban]

Then you should be enlightened:

Of the myriads of existing transfer or serialization formats,

* JSON is still the only secure by default one (if you ignore the two later updates, which made it insecure),

* JSON is by far the easiest to parse (small and secure, no references),

* is natively supported by Javascript.

It has some minor design mistakes, and is not binary (such as msgpack, which is therefore faster), but still is a sane and proper default. Esp. it does not support objects and other extensions, with its initializer problems on MITM attacks, and is properly ended. Unlike XML, YAML, BJSON, BSON, ... which do have major problems, or msgpack, protobuf, ... which do have minor problems.

In every application, any dependency to XML should be minimized, contained and preferably eliminated.

[paulddraper]

> In every application, any dependency to JSON should be minimized, contained and preferably eliminated.

It depends on the extant to which your program needs to communicate/interoperate with other programs...in particular ones without the same programming language (no Java RMI).

Under a "Unix" philosophy, this happens quite a bit.

[einpoklum]

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...

[Kh4L]

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.

[Kh4L]

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

[gumby]

I switched from rapidjson to this library (nlohmann's) because it is so simple to use and integrates into C++ very cleanly.

If I had enormous globs of JSON to read I might use something faster (I believe there's a very fast library that uses SIMD instructions) but my needs are quite limited: basically exchanging snippets of JSON with a network service. So clarity was far more important than performance.

[Teknoman117]

My 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]

Could 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.

[stevekemp]

Kudos 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.

[rienbdj]

The fact that instructions are even required shows how poor the state of c++ packaging is.

[einpoklum]

Actually, a detailed documentation belongs in a Wiki or a separate markdown document, that README.md is a bit much...

[amirmasoudabdol]

This 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]

Yea, 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.

[jchw]

Note 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.)

[baltbalt]

I 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]

Unfortunately template-heavy libraries have to be header-only; otherwise the preprocessor doesn't know which flavors of the template you want to use.

[wodenokoto]

> 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?

[falsedan]

I 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.

[masklinn]

Yes, 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.

[StreamBright]

This is part of it. It is extremly easy to import json and write and read json files and mapping them to Python dicts.

[gsaga]

Yeah, that's probably what they meant.

[omouse]

I'm wondering what the difference between this and json-cpp https://github.com/open-source-parsers/jsoncpp is. They look like they provide the same functionality, albeit this looks more "modern C++ style"?

[boblivion]

For 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.

[umvi]

nlohmann'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.

[mirsadm]

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.

[roryrjb]

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.

[psyclobe]

Its 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.

[etaioinshrdlu]

I used this library on bare metal arduino a year ago. It felt funny doing high level programming on such crappy hardware!

[de_watcher]

We just use the good old Qt JSON parser/generator.

It's basic and has no compilation speed issues.

[pretty_colors]

Gource for this repo: https://youtu.be/cyaCZDffAbQ