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.
JSON for Modern C++
61–70 of 125 posts
Re: JSON for Modern C++
#62Earlier quoted context omitted.
Does anyone write C++ and not care about performance?
On the other hand: I'm a bit surprised at how many people are writing JSON and care about the performance. The overwhelming majority of our IO is reading / writing data files, but those are stored in an optimized binary format. The configuration / metadata accounts for a much smaller fraction of IO. For this tiny fraction we care about flexibility and readability, a slow JSON parser is fine.
While I agree that in many cases JSON parsing is not the largest consumer of resources, it really sucks when it is.
At some point it seems like a general mindset shifted from making things efficient at every level to assuming things don’t matter if you’re probably doing something worse anyway.
Re: JSON for Modern C++
#63Earlier 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…
> 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.
Re: JSON for Modern C++
#64Earlier 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…
> 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.
Often you have control over the sending and receiving parts of an API and can design the transport format to fit your application logic.
For example, I am currently using a GraphQL API and the data structures I get from this API are exactly what I need in my application.
Re: JSON for Modern C++
#65Earlier 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…
> 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
I have this overview:
https://metacpan.org/pod/Cpanel::JSON::XS#SECURITY-CONSIDERA...
which just misses details on stack-overflows on overlarge nesting levels, or denial of service attacks on overlarge strings, arrays or maps.
Better formats which prepended sizes do have an advantage here, such as msgpack. But msgpack has no CRC or digest verification to detect missing or cut-off tails. JSON (its secure 1st RFC 4627) must be properly nested, it does not need this. From the 2nd RFC 7159 on it became insecure, and the 3rd RFC 8259 is merely a joke, as it didn't fix the known issues, only removed a harmless feature.
Re: JSON for Modern C++
#66I 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.
It depends on the extant to which your program needs to communicate/interoperate with other programs...in particular ones without the same programming language (no Java RMI).
Under a "Unix" philosophy, this happens quite a bit.
Re: JSON for Modern C++
#67I 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…
> In every application, any dependency to XML should be minimized, contained and preferably eliminated.
Of course, it's not limited to JSON. For applications, it should be a tiny insignificant detail what format is used for serialization. Be it JSON or some superior format, such as XML.
Re: JSON for Modern C++
#68Earlier 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'…
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.
Re: JSON for Modern C++
#69Earlier 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'…
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 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...
[2]: https://github.com/python/cpython/blob/41c57b335330ff48af098...
Re: JSON for Modern C++
#70Earlier 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…
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!