Boost logo

Boost :

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

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.

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