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

71–80 of 125 posts

Re: JSON for Modern C++

#71

Post by jstimpfle »

rurban wrote: post #63
jstimpfle wrote: post #50

Earlier quoted context omitted.

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

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

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

I made a reasonable attempt at preventing exactly this misunderstanding, but I guess if people want to misread you they will.

> Nobody is talking about application logic here but you.

The application logic (I'm including internal data representation here) is the meat of all efforts, so you should absolutely be considering it, instead of needlessly putting isolated efforts in optimization of side actors. Parsing JSON should IMHO be a total side concern, and using an oversized library like the one we're talking about fails to acknowledge that. Such a library is either a wasted effort (if its data types aren't used throughout the application), or else (if they are) use of the library leads to massive problems down the road.

Re: JSON for Modern C++

#72

Post by jstimpfle »

chucksmash wrote: post #69
rurban wrote: post #63

Earlier quoted context omitted.

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

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

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.

Re: JSON for Modern C++

#73

Post by jstimpfle »

chrisseaton wrote: post #70
jstimpfle wrote: post #38

Earlier quoted context omitted.

Parsing is simple, you just need to be explicit about what you expect to parse. Like, write 10 lines of straightforward parse function (or maybe better, data description + your own code that you use for all your types) that fills your object's fields. Alternatively, if you have a super structured approach about your data (like you're required to have with template metaprogramming) then you can easily generate this st…

> Parsing is simple It's obviously not simple - no two parsers have the same behaviour! http://seriot.ch/parsing_json.php

Tip, if you want to defeat an argument by quoting only three words, make sure you're talking about the same thing.

To be clear, I was not talking about lexing JSON, but about how to configure a "meta-parser" like this library to actually convert some JSON to concrete application data objects. The point of contention was, "should we really use such a massive library or mustn't it be sufficient to have a simple bag of parsing primitives (which we can use to actually build the right thing)".

And I'm not a fan of JSON either...

Re: JSON for Modern C++

#74

Post by rusk »

charliesome wrote: post #68
rurban wrote: post #63

Earlier quoted context omitted.

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

CSV as a format doesn't really exist. CSV is a family of similar but not always compatible data formats each with their own special rules and edge cases. Note that the quote is talking about a well-specified CSV, not any CSV in general. A well-specified CSV would indeed be fairly easy to parse.

> CSV as a format doesn't really exist.

RFC-4180

Re: JSON for Modern C++

#75

Post by chrisseaton »

jstimpfle wrote: post #73
chrisseaton wrote: post #70

Earlier quoted context omitted.

> Parsing is simple It's obviously not simple - no two parsers have the same behaviour! http://seriot.ch/parsing_json.php

Tip, if you want to defeat an argument by quoting only three words, make sure you're talking about the same thing. To be clear, I was not talking about lexing JSON, but about how to configure a "meta-parser" like this library to actually convert some JSON to concrete application data objects. The point of contention was, "should we really use such a massive library or mustn't it be sufficient to have a simple bag of…

Parsing JSON is not simple - not even when you know the structure you're parsing against. For example that reference shows even parsing numbers is not the same everywhere, so that applies even when the structure is as expected.

> Tip, if you want to defeat an argument by quoting only three words, make sure you're talking about the same thing.

Please don't be snarky - if you disagree say so and why.

Re: JSON for Modern C++

#76

Post by jstimpfle »

chrisseaton wrote: post #75
jstimpfle wrote: post #73

Earlier quoted context omitted.

Tip, if you want to defeat an argument by quoting only three words, make sure you're talking about the same thing. To be clear, I was not talking about lexing JSON, but about how to configure a "meta-parser" like this library to actually convert some JSON to concrete application data objects. The point of contention was, "should we really use such a massive library or mustn't it be sufficient to have a simple bag of…

Parsing JSON is not simple - not even when you know the structure you're parsing against. For example that reference shows even parsing numbers is not the same everywhere, so that applies even when the structure is as expected. > Tip, if you want to defeat an argument by quoting only three words, make sure you're talking about the same thing. Please don't be snarky - if you disagree say so and why.

> if you disagree say so and why.

My apologies. Just did that - I'm habitually a post-then-improve type of commenter.

Re: JSON for Modern C++

#77

Post by jstimpfle »

chrisseaton wrote: post #59
stefan_ wrote: post #58

Earlier quoted context omitted.

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.

You shouldn't take major compromises to improve a 90 to a 100, if you could get a 1000 by simply choosing the right approach (like using binary when performance really matters).

Re: JSON for Modern C++

#78

Post by dodobirdlord »

chrisseaton wrote: post #59
stefan_ wrote: post #58

Earlier quoted context omitted.

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.

If you're receiving JSON from outside of your system then the performance talk about converting to objects with fixed offsets and hashmaps with the same layout goes out the window, as you don't control the format.

Re: JSON for Modern C++

#79

Post by jstimpfle »

rusk wrote: post #74
charliesome wrote: post #68

Earlier quoted context omitted.

CSV as a format doesn't really exist. CSV is a family of similar but not always compatible data formats each with their own special rules and edge cases. Note that the quote is talking about a well-specified CSV, not any CSV in general. A well-specified CSV would indeed be fairly easy to parse.

> CSV as a format doesn't really exist. RFC-4180

That was created after how many years of CSV in the wild? Nobody disagrees here that parsing CSV in practice is a horrible minefield with lots of manual adjustments.

Re: JSON for Modern C++

#80

Post by jcranmer »

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.

JSON is effectively a data interchange format. And for data interchange formats, there are reasons to emit property names (for example, because you want humans to be able to read, and maybe even write it). The fact that you want to use JSON as your serialization format shouldn't require you to make your internal data formats use hash tables instead of structs.
Post reply on HN