Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2019-11-17 16:05:47

On 11/17/19 7:40 AM, Peter Dimov via Boost wrote:
> Bjorn Reese wrote:
>> Should there be a JSON archive for Boost.Serialization?
> There are many possible ways to write Boost.Serialization JSON archives,
> depending on the JSON produced. You could for instance output structs as
> `{ "x": 1, "y": 2 }`, or `[ "x", 1, "y", 2 ]`, or `[ 1, 2 ]`, or even `{
> "size": 3, "data": [ 1, 2 ] }`.

> The first representation is the most natural and human-editable,

Human editable archives are something people ask for. But it's not
really possible in a general way because archives have to reflect the
the C++ data structures that they correspond to. If one want's to be
able to edit data off line - better would be to start with a free
standing archive design using something like google protocol buffers.
Then you're into the normal trade offs regarding such libraries.

> but can't be deserialized incrementally ...

Which is pretty much a requirement for a generally function
serialization system.

> Assuming we're talking about the first option, it should be possible to
> use the proposed JSON library to implement a JSON input archive that
> reads from a json::value. The output archive doesn't really need a library.

Implementing json for boost serialization should not be a target
requirement for a json library which is meant to be simple, efficient,
easy to use.

Implementing JSON for boost serialization wouldn't be very hard. I'm
suprised that in 15? years no one has done it. In fact no one has even
asked for it!. Were I to do it, I'd follow the design using boost
spirit which has served me well for many years. It's easy to maintain,
relatively simple to implement, efficient enough so that no one has
complained about when used for xml. It turned xml serializaton ( a dumb
concept I felt I had to implement) into a non-issue.

Robert Ramey

> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at