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.