Boost logo

Boost :

From: Bjorn Reese (breese_at_[hidden])
Date: 2019-11-24 11:53:25


On 11/17/19 3:38 PM, Vinnie Falco wrote:

> Yes these are good questions. I thought I had answered them but it
> could certainly use more explaining (and in the documentation as
> well).

Indeed you did, but thank you for succintly reiterating them anyways.

My question was more directed towards the community as a whole to find
out what they expect of a JSON library.

> In terms of parsing and serialization I don't think there will be any
> single solution that will satisfy all use cases. The emphasis of my
> JSON library is on the container that represents the JSON In memory.
> It is designed to be useful as a vocabulary type. This means that if

Been there, done that years ago:

 
http://breese.github.io/trial/protocol/trial_protocol/dynamic_variable.html

and contributed heavily to its prequel:

   https://github.com/ferruccio/dynamic-cpp

> * `json::value` is small (16/24 bytes on 32/64 bit architecture)

So most (all?) values are stored on the heap?

> This library also supports both incremental parsing and incremental
> serialization using caller-provided buffers, an important use-case for
> building high performing network programs. To my knowledge no other
> JSON library supports this.

Have been doing this for years:

   http://breese.github.io/trial/protocol/trial_protocol/core.html

> These are out of scope for my library. If parser combinators are
> important, they can be developed as a separate library. The same goes
> for bindings for Boost.Serialization and Boost.PropertyTree. Generally
> speaking, I think new Boost library offerings need to be more
> numerous, smaller, modular, and with fewer dependencies from now on. I

The reason I am asking about these questions is that your current design
may not be suitable for making these extensions. You really should
consider building a Boost.Serialization input archive to investigate if
your design holds.

If your design becomes a Boost library, then there will be very little
incentive to include yet another JSON library to handle the remaining
use cases. That is why I am asking these questions up-front.

Notice that with the right design we can support all of these use cases
without making the library more complex.


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