Live data from Hacker News

JSON for Modern C++

github.com

31–40 of 125 posts

Re: JSON for Modern C++

#31

Earlier quoted context omitted.

I lost my mind at this sentence. If feels like a first-class data type because the result of parsing is one of the built-in data types (which can be round-tripped to a similar JSON string). And as soon as you care about serialisation of types it starts feeling incredibly clunky.

Yeah exactly. The equivalent would be to have a JSON parser in C++ which turns a JSON file/object into a C++ object that is accessed in similar ways to other typical C++ objects. So: {"key": value"} becomes json->key = "value" rather than json["key"]. In this library I feel as if they've used operator overloading to emulate the way JSON is used in other languages, rather than making the JSON feel like a first class C…

I think as far as other languages are concerned, the best JSON handling gives youn Serde in Rust and F#, from what I read. If only C++ metaprogramming was easier without crazy complexity, Json library would be made to be much smaller and more efficient with less work.

Re: JSON for Modern C++

#32

Earlier quoted context omitted.

Actually, a detailed documentation belongs in a Wiki or a separate markdown document, that README.md is a bit much...

The wiki is a GitHub thing and will not be included in your git clone. I personally prefer a doc/ folder with RST files in it. That's what the Linux kernel does.

Wikis on GitHub are themselves git repos and can be cloned separately: https://help.github.com/en/articles/adding-or-editing-wiki-p...

Re: JSON for Modern C++

#33

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.

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 this, but it sounds pretty admirable to me.

Re: JSON for Modern C++

#34

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.

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…

WTF indeed. Comment made me check out the source code.. I could only find some headerfiles which a) have the complete implementation in it and b) of course include all dependencies.

This is the exact nonsense that is happening all over the place, and why we need 512GB ram in workstations to compile something.

I can't help but think that some basic knowledge about libraries is missing.

Re: JSON for Modern C++

#35

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 ?

Re: JSON for Modern C++

#36

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…

Why do you need reflection for a message format that requires objects (use hash map) and lists (array or linked list).

Re: JSON for Modern C++

#37
post #11
post #6

I have been using json11 for a few years now ( https://github.com/dropbox/json11 ). It looks like it has been abandoned though. This seems like a great alternative.

I wouldn't say abandoned, it states in the README: Maintenance note: This repo is stable but no longer actively maintained. No further development is planned, and no new feature PRs will be merged. Bug fixes may be merged on a volunteer basis. With JSON being an unchanging spec this makes sense.

Still 13 open issues though. Most of them are marked as enhancement, but 3 as bugs.

Re: JSON for Modern C++

#38

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…

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 stuff. Like, using a usable scripting language or such.

The idea that types can replace code is just broken. The type system is not a programming language. Or at least, as proven by C++/Haskell/..., not a remotely usable one.

Re: JSON for Modern C++

#40

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.

Yep this is why I like JSON Cpp, there's a single-file build and I've had success using it with Repl.it: https://neverfriday.com/2013/07/26/learning-jsoncpp/

Since JSON only has basic data types, it's easy to just parse and retrieve objects, similar to using XML tree parsing libraries back in the day.

Post reply on HN