From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2019-11-24 08:26:30
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
> <boost_at_[hidden]> 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 vector<std::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