Boost logo

Boost :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-09-14 08:31:27

Because of my direct involvement in the C++ Alliance I feel it would be
wrong for me to provide a review that leads to an accept/reject conclusion.

However, I have some experience of integrating this library into a private
project and I felt it might be valuable to share my experiences.

* - What is your evaluation of the design?*

My personal opinion is that the design is sane and well-reasoned. Any areas
with which I have previously taken issue have been raised with the authors
and concerns covered. Some effort was made to explore the effect of ideas I
presented and outcomes were measured. My opinion is that the final design
is largely data-driven.

* - What is your evaluation of the implementation?*

I have found no faults in the implementation during use. There is the
slightly off-putting fact that the default text representation of parsing
integers that are complete powers of 10 are expressed in scientific
notation. Unusual as it seems however, this is strictly conformant with the
JSON standard.

* - What is your evaluation of the documentation?*

The documentation is clear and succinct, the fact that it takes steps to
elucidate the rationale behind design decisions ought to head off a number
of "Wait! Why?" questions.

* - What is your evaluation of the potential usefulness of the library?*

The library has already proven useful to me.

For me personally, the ability to map the parser directly to C++ objects
without going through the intermediate json::value data structure would
offer a minor improvement in performance.

I have started exploring the building of such a parse handler which I
intend to offer as something to go into the examples section at some future
date assuming I have the time to finish it. Notwithstanding, the fact that
I can supply a custom area-style memory resource to the parser/value
largely offsets this concern in practice. Essentially by voiding the
building of the DOM I can avoid one memory allocation and some redundant
copies. In practice, neither one memory allocation nor the memory copies
have proven measurably expensive in my uses of the library.

Whether this ultimately belongs in the JSON library or should be a
dependent library is not for me to say.

It is worth noting that the separation of concerns between parser and
handler is helpful in that it makes this work possible without having to
rewrite any parsing code.

* - Did you try to use the library? With which compiler(s)? Did you have
any problems?*

I have used the library with GCC 9&10, and Clang 9&10. Standards selected
were C++17 and C++20. I chose the boost-dependent (default) option rather
than standalone because I was also using the boost libraries Asio, Beast,
Program Options and System.

* - How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?*

I have written an application that uses the library: A cryptocurrency
market-making bot that faced off to the Deribit websocket/json API.

* - Are you knowledgeable about the problem domain?*

Yes. In a previous market data distribution engine I used Nlohmann JSON
(high level but slow), RapidJSON (low level but fast) and JSMN (super low
level and blindingly fast but no DOM representation, only provides indexes
into data).



On Mon, 14 Sep 2020 at 09:30, Pranam Lashkari via Boost <
boost_at_[hidden]> wrote:

> Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON
> starts today and will run for 10 days ending on 23 Sept 2020. Both of these
> authors have already developed a couple of libraries which are accepted in
> Boost(boost beast and Static String)
> This library focuses on a common and popular use-case for JSON. It provides
> a container to hold parsed and serialised JSON types. It provides more
> flexibility and better benchmark performance than its competitors.
> JSON highlights the following features in the documentation:
> - Fast compilation
> - Require only C++11
> - Fast streaming parser and serializer
> - Easy and safe API with allocator support
> - Constant-time key lookup for objects
> - Options to allow non-standard JSON
> - Compile without Boost, define BOOST_JSON_STANDALONE
> - Optional header-only, without linking to a library
> (a point I would like to add in highlight: it has cool Jason logo 😝)
> To quickly understand and get the flavour of the library take a look at
> "Quick Look"
> <>
> You can find the source code to be reviewed here:
> <>
> You can find the latest documentation here:
> <>
> Benchmarks are also given in the document which can be found here:
> <>
> Some people have also given the early reviews, the thread can be found
> here:
> <>
> Please provide in your review information you think is valuable to
> understand your choice to ACCEPT or REJECT including JSON as a
> Boost library. Please be explicit about your decision (ACCEPT or REJECT).
> Some other questions you might want to consider answering:
> - What is your evaluation of the design?
> - What is your evaluation of the implementation?
> - What is your evaluation of the documentation?
> - What is your evaluation of the potential usefulness of the library?
> - Did you try to use the library? With which compiler(s)? Did you have
> any problems?
> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
> - Are you knowledgeable about the problem domain?
> More information about the Boost Formal Review Process can be found
> here: <>
> Thank you for your effort in the Boost community.
> --
> Thank you,
> Pranam Lashkari,
> _______________________________________________
> Unsubscribe & other changes:

Richard Hodges
office: +442032898513
home: +376841522
mobile: +376380212

Boost list run by bdawes at, gregod at, cpdaniel at, john at