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.