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 going to need a parser of that format for C/C++.
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.
I do not know about everyone, but it I believe it is hard to convert a flexible JSON object into a C++ struct (or something with comparable performance), my understanding is that this library helps with that.
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.
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 going to need a parser of that format for C/C++.