Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2020-09-23 13:21:01

Niall Douglas wrote:

> For the record, I've had offlist email discussions about proposed
> Boost.JSON with a number of people where the general feeling was that
> there was no point in submitting a review, as negative review feedback
> would be ignored, possibly with personal retribution thereafter, and the
> library was always going to be accepted in any case.

Personal retribution, really?

> Consider this: a Hana Dusíková type all-constexpr JSON parser could let
> you specify to the compiler at compile time "this is the exact structure
> of the JSON that shall be parsed". The compiler then bangs out optimum
> parse code for that specific JSON structure input. At runtime, the parser
> tries the pregenerated canned parsers first, if none match, then it falls
> back to runtime parsing.

That's definitely an interesting research project, but our ability to
imagine it does not mean that people have no need for what's being
submitted - a library with the speed of RapidJSON and the usability of JSON
for Modern C++, with some additional and unique features such as incremental

To go on your tangent, I, personally, think that compile-time parsing is
overrated because it's cool. Yes, CTRE is a remarkable accomplishment, and
yes, Tim Shen, the author of libstdc++'s <regex> also thinks that
compile-time regex parsing is the cure for <regex>'s ills. But I don't think
so. In my unsubstantiated opinion, runtime parsing can match CTRE's
performance, and the only reason current engines don't is because they are
severely underoptimized.

Similarly, I doubt that a constexpr JSON parser will even match simdjson,
let alone beat it.

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