
JSON for Modern C++ - gballan
https://github.com/nlohmann/json
======
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.

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

~~~
jstimpfle
> JSON is still the only secure by default one (if you ignore the two later
> updates, which made it

How can a data format be insecure?

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

It's relatively easy to parse (while not as easy as a sane well-specified
version of CSV would be). But it also offers no structural integrity, which
means that you need to augment the parsing code with terribly ugly validation
code. (I don't really use JSON frequently, but the attempts at providing a
principled validation framework on top of JSON that I've seen were...
unsatisfying).

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

That's missing the point. It's not about JSON vs XML vs whatever. It's that
application logic shouldn't be operating on transport data formats. And even
if JSON has a simple representation as runtime data objects (in most scripting
languages), that representation is pretty far from ideal compared to a
representation tailored towards your specific application logic.

~~~
rurban
> It's relatively easy to parse (while not as easy as a sane well-specified
> version of CSV would be).

Wrong. CSV is horrible to parse with its string quoting rules. JSON accepts
only utf8 and is not misleaded by \, nor ",". Done both, JSON is much simpler
and can represent nested structures, arrays or maps. CSV importers are mostly
broken, and should be left to Excel folks only.

> It's that application logic shouldn't be operating on transport data formats

Nobody is talking about application logic here but you. JSON is one of the
best transport data formats, and this library makes it much easier to
encode/decode from/to JSON and C++.

We are not talking about javascript's hack to prefer JSON over full objects.
Of course is an internal representation always better than an external, esp.
such a simplified one. But for transports simple ones are preferred over
complicated serialized ones, because then you can easily do MITM stack-
overflows or abusing side effects on creating arbitrary objects.

~~~
chucksmash
Exactly this.

If you didn't do a compilers class and you want a simple language to play
around with for lexing/parsing, JSON works great. Here's the core of a
probably correct JSON lexer, albeit a super inefficient one, that I whipped up
in <110 lines of Python a few years ago out of curiosity[1].

By comparison, check out the state machine transitions at the heart of the
cpython implementation of the csv module[2]. It's not really a fair comparison
(my JSON lexer is written in Python and uses regexes, the csv parser is
written in C and does not use regexes) but even ignoring how nicely the csv
parser handles different csv dialects, I still find it strictly more complex.

[1]:
[https://github.com/chucksmash/jsonish/blob/master/jsonish/to...](https://github.com/chucksmash/jsonish/blob/master/jsonish/tokens.py)

[2]:
[https://github.com/python/cpython/blob/41c57b335330ff48af098...](https://github.com/python/cpython/blob/41c57b335330ff48af098d47e379e0f9ba09d233/Modules/_csv.c#L591)

~~~
jstimpfle
You misread me as well. I'm not saying that CSV is a good format. It's not,
because it is ill-specified.

All I'm saying is that flat database tuples are even easier to parse than JSON
(which is nested, so requires a runtime stack). It was a total side note (in
parentheses!).

My main argument is that JSON is a mess to validate.

------
einpoklum
How 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-J...](https://www.codeproject.com/Articles/20027/JSON-Spirit-A-C-JSON-
Parser-Generator-Implemented)

~~~
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/](http://cocodataset.org/)
metadata files and RapidJson is 100% faster.

~~~
doublerebel
RapidJson 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)

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

~~~
dasloop
No, 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
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.

~~~
Thorentis
Yeah 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
I 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.

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

~~~
omouse
Fuzzed? That's a rarity in tests, that's awesome!

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

~~~
nurettin
People 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.

------
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](https://youtu.be/cyaCZDffAbQ)

