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

41–50 of 125 posts

Re: JSON for Modern C++

#41

Post by kyberias »

jcelerier wrote: post #35
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.

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

When implementing that protocol, dependency to JSON should be minimized, contained and preferably eliminated.

Re: JSON for Modern C++

#42

Post by omouse »

Betelgeuse90 wrote: post #33
jstimpfle wrote: post #28

Earlier quoted context omitted.

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

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…

Reflection isn't required; keys in JSON are strings, and there are basic data types that are supported (strings, numbers, booleans, arrays, and dictionaries which are more of the same).

What's wrong with writing "initializers" which are serializers/deserializers? If you're looking for automatic file format to C++ class object, why settle for JSON (whether it's this library or JSONCpp) why not use Thrift or Protocol Buffers?

- Thrift: https://thrift.apache.org/ - Protocol Buffers: https://developers.google.com/protocol-buffers/

Re: JSON for Modern C++

#43

Post by boblivion »

omouse wrote: post #39

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

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.

Re: JSON for Modern C++

#44

Post by jstimpfle »

jcelerier wrote: post #35
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.

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

JSON is just a transport. Get the payload off from library structures to your own data structures ASAP, to remove dependencies, and to profit from your own setup.

And how to make the transformation? Using your own setup. No point in expressing (duplicating!) your own data structure definitions in a random library's DDL (which, apart from the inflicted duplication, will not fit very well since it doesn't know your project).

Re: JSON for Modern C++

#45

Post by omouse »

boblivion wrote: post #43
omouse wrote: post #39

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

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.

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

Re: JSON for Modern C++

#46

Post by StreamBright »

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.

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.

Re: JSON for Modern C++

#47

Post by StreamBright »

wodenokoto wrote: post #4

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

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

Re: JSON for Modern C++

#48

Post by rurban »

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

Re: JSON for Modern C++

#49

Post by gdy »

vips7L wrote: post #21
Kh4L wrote: post #12

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 that's a configuration file which is read once - yes

Re: JSON for Modern C++

#50

Post by jstimpfle »

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

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.

Post reply on HN