Gource for this repo: https://youtu.be/cyaCZDffAbQ
JSON for Modern C++
81–90 of 125 posts
Re: JSON for Modern C++
#82I 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.
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.
Re: JSON for Modern C++
#83Earlier 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…
But this advice only really applies to projects where you create every service and layer. If you want to incorporate a 3rd party service, or want to allow your service to be used by others, you need some sort of common format. JSON isn't the most efficient, but it gets a lot of exposure from being a first class citizen of the web. Msgpack is good if you want efficiency. But you need something if you want your program to communicate with others.
Re: JSON for Modern C++
#84How 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...
I switched from rapidjson to this library (nlohmann's) because it is so simple to use and integrates into C++ very cleanly.
If I had enormous globs of JSON to read I might use something faster (I believe there's a very fast library that uses SIMD instructions) but my needs are quite limited: basically exchanging snippets of JSON with a network service. So clarity was far more important than performance.
Re: JSON for Modern C++
#85Earlier quoted context omitted.
> 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.
You can meet an expected format in a fast path, and have a slow path fallback where it doesn’t meet and expected format.
Re: JSON for Modern C++
#86I 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.
I can tell this is a C++ thread, heaven forbid you touch anything new within the last 20 years...
The JSON obsession is that everything under the moon supports it- and it's a nice easy structure which can be converted to a dynamic or statically typed object with no issues. Plus it's very human readable, so it's great for debugging.
If you sit there and ONLY use C++, ok why bother? But many systems need to talk to different systems these days. I can setup a webapi that can communicate with my angular typescript, C#, matlab all through nice easy JSON. Each language just converts it to the object and I'm good to go.
The question is why are you so against such a widely accepted format of communication?
Re: JSON for Modern C++
#87How 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...
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
This is a very convenient library for getting started. It even has a mode that made it possible for me to parse numbers into a decimal class.
I would point out that its convenience in large part depends on extensive use of cast operators, which can lead to some tricky corner cases. It is also the only component in one of my projects that confuses xlclang++ on AIX.
Re: JSON for Modern C++
#88Earlier quoted context omitted.
> 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)…
Could you elaborate on how are the 2nd and 3rd versions insecure and a joke? I've reread them and see no issues with either. Basically apart from clarifications and fluff about limits, security, and interoperability the only differences in the JSON spec itself are allowing any value at the top level and requiring UTF-8 for cross-system exchange.
Since UTF-8 is the only sensible format for JSON it makes little sense to require UTF-16 and UTF-32 support. ( unless you have some special requirements on encoding, in which case you can just disregard that part and convert it on both ends yourself )
The only "issue" with non-object values I see is the one mentioned in the above link where naively concatenating JSON might lead to errors when you send two consecutive numbers but that's going to rarely happen so your system can just reject top-level numbers if it doesn't expect them. And even then the simple solution is to just add whitespace around it.
Re: JSON for Modern C++
#89You know it's a hipster repo when there are emojis in the commit messages. Also, header-only libraries suck for compile times. Need to be abstracted with impl-pimpl idiom to compile in a sane amount of time again. No thanks.
Re: JSON for Modern C++
#90I 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.
If you don't understand why your application requires marshalling/serialisation, you never wrote a real application. You question goes away as soon as you do.