JSON for Modern C++ • Hacker News Board

Re: JSON for Modern C++

#101

Post by jarjoura » Sun, Sep 29, 2019, 9:27 PM UTC

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.

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.

Re: JSON for Modern C++

#102

Post by afiori » Sun, Sep 29, 2019, 9:29 PM UTC

snagglegaggle wrote: post #96

umvi wrote: post #91

Earlier quoted context omitted.

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

I think TOML is better, maybe with some modifications. I dislike that it has a person's name in it though; maybe we retcon it to Text Object Markup Language. TOML has inline and multiline forms for most objects.

but in this context TOML and JSON are almost isomorphic (ok, parsing JSON is more unreliable than many realize apparently). As far as I can see the problem is that it is difficult to convert arbitrary JSON object to C++ objects. TOML (I also like it, for different reasons) isn't gonna help with that.

Re: JSON for Modern C++

#103

Post by etaioinshrdlu » Sun, Sep 29, 2019, 9:33 PM UTC

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

Re: JSON for Modern C++

#104

Post by shultays » Sun, Sep 29, 2019, 9:46 PM UTC

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?

You dont necerrarily need to care for everything to be performant.

Re: JSON for Modern C++

#105

Post by biggestdecision » Sun, Sep 29, 2019, 11:10 PM UTC

omouse wrote: post #42

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…

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

>why settle for JSON

Because I'm not writing code in a vacuum, and JSON is what everyone else is using. JSON is chosen for simplicity & interoperability.

Re: JSON for Modern C++

#106

Post by snagglegaggle » Mon, Sep 30, 2019, 12:29 AM UTC

afiori wrote: post #102

snagglegaggle wrote: post #96

Earlier quoted context omitted.

I think TOML is better, maybe with some modifications. I dislike that it has a person's name in it though; maybe we retcon it to Text Object Markup Language. TOML has inline and multiline forms for most objects.

but in this context TOML and JSON are almost isomorphic (ok, parsing JSON is more unreliable than many realize apparently). As far as I can see the problem is that it is difficult to convert arbitrary JSON object to C++ objects. TOML (I also like it, for different reasons) isn't gonna help with that.

Wait, everyone is complaining you can't do `object.member.submember`? I don't see the issue with object['member']['sub']. It is slightly more typing, but such is life.

Re: JSON for Modern C++

#107

Post by theamk » Mon, Sep 30, 2019, 1:10 AM UTC

CoolGuySteve wrote: post #97

devwastaken wrote: post #82

Earlier quoted context omitted.

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.

For config files at least, I've moved entirely to ini format. Python's configparser is handy for machine generating complicated configs and the nesting/list support in JSON adds way more complexity than I need compared to just using comma separated lists as values. This is my entire ini parser for making a std::map . I cast/parse the values at the use site: std::regex section_test("\\[(.*?)\\]"); std::regex value_tes…

Our project is using something like that - it started nice and simple, but got lots of ugly hacks now. We have some values which use two different sub-delimiters, multiple “mini-formats”, values which contain the name of other keys, magic atrings to represent “null”, and so on.

We got used to this, but results are pretty ugly. We get people confused about delimiter order, broken copy-paste, and so on. For the next project, I’d recommend something which can support complex structures. A schema validation would be nice, too.

Re: JSON for Modern C++

#108

Post by umvi » Mon, Sep 30, 2019, 4:02 AM UTC

snagglegaggle wrote: post #106

afiori wrote: post #102

Earlier quoted context omitted.

but in this context TOML and JSON are almost isomorphic (ok, parsing JSON is more unreliable than many realize apparently). As far as I can see the problem is that it is difficult to convert arbitrary JSON object to C++ objects. TOML (I also like it, for different reasons) isn't gonna help with that.

Wait, everyone is complaining you can't do `object.member.submember`? I don't see the issue with object['member']['sub']. It is slightly more typing, but such is life.

It's better to do object.at("member").at("sub") so that it throws an exception instead of seg faulting if one of the keys doesn't exist

Re: JSON for Modern C++

#109

Post by snagglegaggle » Mon, Sep 30, 2019, 4:49 AM UTC

umvi wrote: post #108

snagglegaggle wrote: post #106

Earlier quoted context omitted.

Wait, everyone is complaining you can't do `object.member.submember`? I don't see the issue with object['member']['sub']. It is slightly more typing, but such is life.

It's better to do object.at("member").at("sub") so that it throws an exception instead of seg faulting if one of the keys doesn't exist

Sure, I was kind of envisioning overloading []. It did make me think though: perhaps it is best to have an embedded interpreter for accessing member items? It is what gcrypt does, actually -- embedded lisp syntax. I always wondered why and I think now I know.

Re: JSON for Modern C++

#110

Post by jcelerier » Mon, Sep 30, 2019, 8:35 AM UTC

jstimpfle wrote: post #44

jcelerier wrote: post #35

Earlier quoted context omitted.

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

> Get the payload off from library structures to your own data structures ASAP,

I don't understand, doing this step is exactly why you need to have a library such as the one which is being discussed here. There's no in-language way in C++ to go from a string that looks like `{ "foo": [1,2,3] }` to `struct { int foo[3]; }`.