Boost logo

Boost :

From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2020-09-22 10:23:24


Em seg., 21 de set. de 2020 às 23:02, Peter Dimov via Boost
<boost_at_[hidden]> escreveu:
> The easiest way to make a JSON input archive for Boost.Serialization is to
> use Boost.JSON and go through json::value. Boost.Serialization typically
> wants fields to appear in the same order they were written, but JSON allows
> arbitrary reordering. Reading a json::value first and then deserializing
> from that is much easier than deserializing directly from JSON.
>
> For output, it's easier to bypass json::value and write JSON directly.

It may be easier, but it's also the wrong way. There are libraries
whose usage patterns leak some structure into user code itself. We
have Lua and its virtual stack, for instance. Boost.Serialization is
one of such libraries. That's really a topic that I'd rather delay the
explanation on.

Boost.Serialization un-capturable structure makes it impossible to
untangle the serialization format from ordered trees. For a JSON
archive, this means arrays everywhere, and json::value doesn't really
help here.

But there's a catch. The user can have very valid concerns to control
serialization to just one archive or another. Here's where he'll
overload his types directly to a single archive. And here's where he
can use archive extensions from one model. For the JSON iarchive, the
only extension we need to expose is the pull parser object. This and
some accompanying algorithms (json::partial::skip(),
json::partial::scanf(), ...) is a much better answer than what you
propose.

It's not really hard if you understand the pull parser model. But I'm
more excited about Boost.Hana's Struct integration actually. We can
discuss all in detail after Boost.JSON's review. Please don't
misdirect discussions with comments such as "it'd be easier with
json::value". That's hardly a comment from somebody who explored the
subject.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk