Re: New JSON library from the maker of Beast!

From: Daniel Frey (d.frey_at_[hidden])
Date: 2019-09-23 11:14:47

> On 23. Sep 2019, at 13:06, Glen Fernandes via Boost <boost_at_[hidden]> wrote:
> 
> On Mon, Sep 23, 2019 at 6:44 AM Glen Fernandes  wrote:
>> On Mon, Sep 23, 2019 at 5:19 AM Dominique Devienne via Boost
> 
>>> Also, in client/server communications, it's less often a few huge JSON
>>> documents, but rather lots of small documents, so the constant "startup"
>>> time of the parser matters too, and in that same vein, a PULL-parser that
>>> allows to build the native data-structures directly, rather than the
>>> DOM-like
>>> approach of fully converting the document to a built-in JSON object, and
>>> then convert that to the native-structure, avoids the temp document, which
>>> is especially useful for large documents.
>>> 
>> 
>> It looks like nlohmann/json now has this kind of API too:
>> 1. https://tinyurl.com/nl-json-parse
>> 2. https://tinyurl.com/nl-json-parse-callback
>> 
> 
> That is the use case that I find more interesting. If you want to
> decouple your data representation in your  program from the
> serialization format.
> 
> e.g. In memory if your data structure is something like:
>    vector<map<string, pair<int, double> > >.
> 
> This could be expressed in json by something like:
>    [   { "key": [1, 0.01],   "def": [9, 0.37], ... },
>        { "xyz": [5, 1.25],   "abc": [2, 4.68], ... },
>     ... ]
> 
> Your load it from some JSON file.  Your don't want to store/use it in
> your program as a SomeLibrary::JsonArray. Past the point of
> serialization it should be your own data structures.  Of course your
> could always convert it from SomeLIbrary::JsonArray to your own
> structures, but that's overhead you don't need if there's hundreds of
> megabytes worth of content in that data.
> 

Just throwing our library in the ring: https://github.com/taocpp/json

We have a SAX-style interface at the core, parsers only generate events, from there you can generate a DOM object or some direct UDT structure like mentioned above. (Uses some macros to register types). Or you directly pretty print it or convert to CBOR, MsgPack, etc.

You could even generate an nlohmann-DOM-value with our parsers. Benchmarks in the nativejson-benchmark showed that we were faster than nlohmann's builtin parser (that was some time ago, might have changed in the meantime)

Currently, our parser(s) do not support incremental parsing, though. 

Daniel

> Glen
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost