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.