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.
But if the value gets larger, the parser will not call on_uint64, it will call on_double.
The text to binary conversion shouldn't even be in the JSON parser,
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.
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.
Yeah, fair point.