Boost logo

Boost :

From: Gavin Lambert (boost_at_[hidden])
Date: 2020-09-23 13:43:16

At 00:22 24/09/2020, Vinnie Falco wrote:
>On Wed, Sep 23, 2020 at 1:40 AM Gavin Lambert wrote:
>> I've walked back on that one a little bit; I now think that
>ok for
>> basic_parser to do that (to retain a zero-allocation
>but in
>> that case it should treat numbers the same way (which it
>> doesn't), and ideally there should be a standard
>> parser that has a similar interface but does preassemble the
>> eliminating the _part callbacks (for people who prefer ease of

>use over
>> raw performance).
>I had that originally, it was called number_parser, it was a
>interface, and it was one of the first things to go during our
>journey of optimization. You can fish it out of the commit log
>care to see it.

I didn't fish out the code, but given the class name, that sounds
like the complete opposite of what I was suggesting.

To restate again, my suggestion is:

1. Remove on_int64/uint64/double from basic_parser's handler type.
2. Add on_number(string_view, size_t) to basic_parser's handler
type -- having exactly the same semantics as on_key/string and
their _part companions.
3. Add custom_parser, which wraps a basic_parser but has internal
(dynamically allocated if needed) storage for partial
keys/strings/numbers so it never calls _part methods on its own
handler type. It still uses on_number(string_view) but note that
this (and on_key/string) have no reason to pass a size_t any more,
because it can never be any different from the size() of the
4. The int64/uint64/double parsing code that used to be in
basic_parser should be moved to a dedicated helper class, in turn
used by parser and *optionally* used by the user's handler
implementation for basic_parser/custom_parser.

This design has the proper separation of concerns between the
parser layers (not dictating a numeric storage format, and keeping
number parsing separate from JSON structural parsing). It should
not negatively impact performance of parser, and should positively
affect performance of basic/custom_parser consumers who didn't
want the default conversion anyway.

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