On Sun, Sep 22, 2019 at 5:46 PM David Bellot via Boost
- 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/25ddea5f4d088f3e56911bf9f97549eeb93... * Insert order control, e.g https://github.com/vinniefalco/json/blob/25ddea5f4d088f3e56911bf9f97549eeb93... * 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/25ddea5f4d088f3e56911bf9f97549eeb93... * 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/e4b085d3523047ffe8fa0c910592... 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: https://github.com/vinniefalco/BeastLounge/blob/e4b085d3523047ffe8fa0c910592... 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/25ddea5f4d088f3e56911bf9f97549eeb93...