Re: [review] [json] My JSON review

From: Peter Dimov (pdimov_at_[hidden])
Date: 2020-09-21 15:56:20

Mathias Gaunard wrote:
> > OK, if you don't need the text to binary conversion, what's stopping you 
> > from ignoring it, and only using the text part? You do get all the info, 
> > it's just that the final part doesn't arrive via "on_number", but via 
> > the other three callbacks, to save one call.
>
> Separation of concerns, wasted cycles, etc.
> Parsing numbers is the slowest part of all this parsing business, and the 
> part that's most dependent on how you want to represent numbers into 
> memory.
>
> For example I typically represent numbers as decimals myself.

Right. So you acknowledge that the parser as-is would work for your use 
case, but you refuse to use it, and prefer Boost not to have it, because 
separation of concerns and wasted cycles. You intuitively feel that it would 
be too slow because it converts the numbers into int64/double, but haven't 
measured it against a parser that doesn't. (If you do, you may be 
surprised.)

FWIW, there's a reason concerns aren't separated here. It's that the number 
can be arbitrarily long, so if you're going to separate the concerns, you'd 
need to buffer the entire number in string from before being able to convert 
it to int64/uint64/double. But since these have limited precision, if you do 
the conversion on the fly, you no longer need to buffer the entire number in 
string form. If the user wants the entire number, he can buffer it himself. 
If not, that part is unnecessary and isn't done.

Since the majority of users are more interested in int64/uint64/double than 
in infinite precision, the parser chooses to favor this case at the expense 
of the other, and not vice versa.