Re: [review] [json] My JSON review

From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2020-09-21 14:26:45

On Mon, 21 Sep 2020 at 14:44, Peter Dimov via Boost
<boost_at_[hidden]> wrote:
>
> Mathias Gaunard wrote:
>
> > - The lack of proper number support from the DOM apparently propagates to
> > the parser as well, even though there is no cost for the parser to
> > properly support them.
>
> In what way does it apparently propagate?

Assuming you have the number 12345678909876543210, which is striding
two buffers, with 1234567890 then 9876543210, the parser will call

uint64 value = 0;

value = value * pow10(size("1234567890")) + 1234567890;
on_number_part("1234567890", ec)

value = value * pow10(size("9876543210")) + 9876543210;
on_uint64(value, "9876543210", ec)

(the actual implementation works on character per character basis and
is slower than this)
This will not really work once the value gets one digit larger, as the
first argument will be garbage.

The text to binary conversion shouldn't even be in the JSON parser,
that's an orthogonal concern that's only needed for json::value.
If you want to do that, you can just easily implement it in
json::parser, the handler in charges of building json::value (which is
currently a no-op for on_number_part).

> > The way the parser interfaces handles numbers is not only inconsistent
> > with the rest of its interface but also limiting.
>
> What are the limitations, and what is `n` in your suggested replacement?

Same as for on_string_part/on_string, on_key_part/on_key,
on_comment_part/on_comment etc.
I'm arguing it should be there for consistency, it's not strictly necessary.