From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-09-20 05:17:44
I vote to accept Boost.JSON. I spent a couple of hours reading the
documentation and some of the source code. I dug into some of the
implementation details, it's all high quality C++.
The documentation is generally excellent. It would be nice if the main page
includes a link to the GitHub repo.
The design is intuitive and beginner-friendly. At the same time, I
appreciate the intricacies of designing a simple interface that is also
fast. I especially appreciate that the authors have not fallen into the
policy-based design trap. This is perhaps the main reason why the interface
is so clean.
There is no reason why the "non-standalone" version of Boost.JSON is not
able to communicate errors in terms of std::error_code via additional
overloads. The same may be true about other Boost components that are also
available in C++17, but I appreciate that this may not not be quite as
straight-forward as supporting std::error_code.
I dislike putting documentation inline with source code a-la doxygen. If I
want to read the documentation, I'd read the documentation, and if I don't
it just gets in the way of reading C++. Other than that, it's well written.
It is obvious that a lot of thought went into naming things correctly,
which I appreciate.
I didn't try using the cmake build, but running the tests by simply
invoking b2 did not work; I had to specify cxxstd=11 by hand. This should
In conclusion, I'm looking forward to refactoring my code base to use
Boost.JSON if it is accepted (it currently uses jsmn which I've wrapped in
a thin layer of C++).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk