|
Boost : |
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-09-23 01:44:27
On Sun, Sep 22, 2019 at 5:46 PM David Bellot via Boost
<boost_at_[hidden]> wrote:
> - can you provide a point-by-point comparison with this other great
> library: https://github.com/nlohmann/json?
Features in nlohmann but not planned for Boost.JSON:
* JSON Pointer
* JSON Patch
* Specializing enum conversion
* Binary formats (BSON, CBOR, MessagePack, and UBJSON)
* Output format control
* A bunch of syntactic sugar
Features in Boost.JSON but not in nlohmann:
* Full allocator support
To my knowledge, nlohmann JSON only supports allocators which are
DefaultConstructible. Boost.JSON gives full control over allocation
and uses a type-erased, reference counted allocator almost identical
to the polymorphic allocators in the standard. The library enforces a
simple invariant: All elements which are part of the same JSON
"document" (i.e. all share a common ancestor) are guaranteed to use
the same. This is enforced at runtime: when an element which uses a
different allocator is moved into a container, it is instead copied to
use the same allocator as the container (and thus the enclosing JSON
document).
* Object elements are also sorted on insertion order:
Iterating a JSON value of object type visits the elements in the order
of insertion.
<https://github.com/vinniefalco/json/blob/25ddea5f4d088f3e56911bf9f97549eeb938b9b5/include/boost/json/object.hpp#L30>
* Insert order control, e.g
<https://github.com/vinniefalco/json/blob/25ddea5f4d088f3e56911bf9f97549eeb938b9b5/include/boost/json/object.hpp#L247>
* C++20 conforming container APIs
Including node_type, remove values from an object and reinsert them
elsewhere, or live outside the container:
<https://github.com/vinniefalco/json/blob/25ddea5f4d088f3e56911bf9f97549eeb938b9b5/include/boost/json/object.hpp#L312>
* Elements are implemented using non-template classes, most of the
function definitions may be compiled and linked through a static or
shared library. A header-only option is also available (via
configuration macro)
* The parser and serializer are designed to work incrementally.
However, the parser interface allows the caller to inform the parser
when the entirety (or remainder) of the JSON document is present. This
enables the parser to use a different algorithm when it is known ahead
of time that the entire document is available (currently, the
implementation does not take advantage of this feature but it is
possible in the future).
* The parser uses error codes. The implementation does not allow
exceptions to be raised from untrusted inputs.
* User-defined types can be exchanged to and from JSON value objects in 3 ways:
- by writing a free function which is found via ADL for the type,
- by adding member functions with conforming signatures for class types, or
- by specializing a class template for the type
Here is an example of specialization to allow Boost.Asio IP address to
be constructed from a JSON value:
<https://github.com/vinniefalco/BeastLounge/blob/e4b085d3523047ffe8fa0c910592234da2aaea34/server/server.cpp#L53>
There is still some implementation left in my library so it should be
considered as an early beta software. BeastLounge runs on it, you can
see example code that uses it here:
With respect to nlohmann, the initial version 1.0 of Boost.JSON will
certainly not be as feature rich. Instead, I plan to focus on the
areas where I think it can offer things lacking in other JSON
libraries and do so with the high standards the community has come to
expect from Boost libraries.
> - would it be able to interact with property_tree too?
I don't plan on introducing a dependency on Boost.PropertyTree. The
parser is structured the same way as the Beast HTTP parser. The
algorithm is encoded into an abstract base class which is subclassed
to output into the JSON container. If desired, you can subclass the
parser yourself to store the results in a property tree:
<https://github.com/vinniefalco/json/blob/25ddea5f4d088f3e56911bf9f97549eeb938b9b5/include/boost/json/basic_parser.hpp#L157>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk