Re: [boost] Jason is getting MARRIED!

Le samedi 23 novembre 2019 à 11:11 -0800, Vinnie Falco via Boost a écrit :

On Sat, Nov 23, 2019 at 10:37 AM Lee Clagett via Boost wrote:

...

The bulk of cases are JSON -> specific data structure. The easiest implementation for JSON objects in C++ is storing all fields to a temporary DOM and then doing a lookup when mapping to a data structure.

This is an important use-case, but there are several libraries out there which support this. The innovation in Boost.JSON is providing a vocabulary type for the DOM that uses the discriminated union (the `boost::json::value`).

Not sure why you say this is an innovation. Maybe i missed something, but i dont see this much different than https://doc.qt.io/qt-5/qjsonvalue.html , which is around for years.

This way folks can build up layers of abstraction using a common interface. Boost.JSON also performs well, which is a bonus. And it is the first library to support incremental parsing and serialization, which makes it a natural choice for network programs.

This is imho the major feature in boost.json. This was in fact the main reason i started writing my own json library some years ago.

Lets say you have this JSON:

{ "id" : 42, "name" : "John Doe", "invoices" : [ 1001, 1002, 1005, 1007 ] }

The output of the parser is a json::value which holds result. The top level value is an object, with 3 elements. Because json::value is SemiRegular and has a sane API, you could easily turn the parsed DOM into this structure:

While it is ok for most use cases, if talking about performance you probably don't want your DOM intermediate structure. You want a deserializer that just directly create a customer structure without any intermediate. And you’ll just use a vectorstd::uint64_t for invoices. and an std::string for name. Same goes for the serializer. But the nice thing is that from what i see, it is entirely possible to do with current boost.json (didn't check about the serializer part, though).

Remember that the thesis of this library is "no single JSON library can or should satisfy all use-cases." What I have done (hopefully) is identified a common use-case that benefits from some form of standardization, to provide a vocabulary type for a JSON.

Using json types directly is fine for prototyping, for quickly written code that is not supposed to last for years. There is a market for this, this is useful. However, i would not rely on it for any code that is supposed to last or be reused amoung projects. Regards, Julien