Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON for Modern C++

github.com

Post reply on HN
Print view View original

51–60 of 125 posts

Re: JSON for Modern C++

#51

Post by chrisseaton »

cocoa19 wrote: post #36
Betelgeuse90 wrote: post #33

Earlier quoted context omitted.

Recently 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 thi…

Why do you need reflection for a message format that requires objects (use hash map) and lists (array or linked list).

I think because looking up in a hash map is going to be bad for performance. You want it in an object so you can use fixed offsets. And using individual hash maps for each object is wasteful if they all have the same layout.

Re: JSON for Modern C++

#52

Post by legulere »

jstimpfle wrote: post #50
rurban wrote: post #48

Earlier quoted context omitted.

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 s…

> 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 u…

> How can a data format be insecure?

XML external entities allow for arbitrary file inclusion: https://en.wikipedia.org/wiki/XML_external_entity_attack

You can make a badly configured XML parser allocate memory until it crashes: https://en.wikipedia.org/wiki/Billion_laughs_attack

You cannot host user-generated xmls on a domain without making yourself vulnerable to cross site scripting attacks. Browsers will happily execute any javascript you include: https://stackoverflow.com/questions/384639/how-to-include-ja...

Re: JSON for Modern C++

#53

Post by josefx »

rurban wrote: post #48
kyberias wrote: post #20

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.

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 s…

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

And enough people put it into eval that several companies started prepending while(1); to their JSON messages. Don't blindly trust user input no matter what format it comes in.

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

We all know its definition fits on a business card, which is the reason we have at least seven different specifications[1] on the details omitted from the card.

[1]http://seriot.ch/parsing_json.php

Re: JSON for Modern C++

#54

Post by [deleted] »

kyberias wrote: post #20

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.

[deleted]

Re: JSON for Modern C++

#55

Post by doublerebel »

Kh4L wrote: post #9
einpoklum wrote: post #7

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.

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

Re: JSON for Modern C++

#56

Post by ryandrake »

amirmasoudabdol wrote: post #3

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.

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.

Re: JSON for Modern C++

#57

Post by __MatrixMan__ »

jstimpfle wrote: post #50
rurban wrote: post #48

Earlier quoted context omitted.

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 s…

> 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 u…

> How can a data format be insecure?

If it tries to be too featureful, then it requires parsers to be very flexible. Malicious input can trick a too-flexible parser into doing things that the developer of whatever function called the parser probably didn't want to happen.

For example, YAML:

https://arp242.net/yaml-config.html

Re: JSON for Modern C++

#58

Post by stefan_ »

chrisseaton wrote: post #51
cocoa19 wrote: post #36

Earlier quoted context omitted.

Why do you need reflection for a message format that requires objects (use hash map) and lists (array or linked list).

I think because looking up in a hash map is going to be bad for performance. You want it in an object so you can use fixed offsets. And using individual hash maps for each object is wasteful if they all have the same layout.

If performance is a concern, why on earth are you using JSON. Just the absurd amount of string-integer conversions kill any hope of that.

Re: JSON for Modern C++

#59

Post by chrisseaton »

stefan_ wrote: post #58
chrisseaton wrote: post #51

Earlier quoted context omitted.

I think because looking up in a hash map is going to be bad for performance. You want it in an object so you can use fixed offsets. And using individual hash maps for each object is wasteful if they all have the same layout.

If performance is a concern, why on earth are you using JSON. Just the absurd amount of string-integer conversions kill any hope of that.

> If performance is a concern, why on earth are you using JSON.

Maybe JSON is what you get sent and you've got no control over that? Or JSON is what you want to expose and you've got no control over that either? You can want to achieve reasonable performance while still meeting external requirements.

Re: JSON for Modern C++

#60

Post by eropple »

frou_dh wrote: post #32
panpanna wrote: post #13

Earlier quoted context omitted.

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

Wikis on GitHub are themselves git repos and can be cloned separately: https://help.github.com/en/articles/adding-or-editing-wiki-p...

Yeah, but they have to be cloned separately. And not all projects have them.

A doc directory gets you the same thing, easier.

Post reply on HN