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). Regards, R On Mon, 14 Sep 2020 at 09:30, Pranam Lashkari via Boost < boost@lists.boost.org> 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" http://master.json.cpp.al/json/usage/quick_look.html
You can find the source code to be reviewed here: https://github.com/CPPAlliance/json/tree/master
You can find the latest documentation here: http://master.json.cpp.al/
Benchmarks are also given in the document which can be found here: http://master.json.cpp.al/json/benchmarks.html
Some people have also given the early reviews, the thread can be found here: https://lists.boost.org/Archives/boost/2020/09/249745.php
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: http://www.boost.org/community/reviews.html
Thank you for your effort in the Boost community.
-- Thank you, Pranam Lashkari, https://lpranam.github.io/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212