On 23/09/2020 18:31, Julien Blanc wrote:
The base inconsistency is the fact that storing a number, whatever large it is, takes a fixed amount of storage (talking about doubles or longs, which are the only types handled by boost.json), whereas for a string it is not the case. A non-allocating parser can safely handle integers and double itself (and it can do it in a more efficient way than if it's done in an upper layer), but has no other choice than splitting strings (unless there is an upper limit on string size).
I'm aware of that (although it's not entirely true). My point is that it's the wrong thing to do, especially given that JSON technically allows for arbitrarily large numbers (even though is typically more limited in practice). This could be avoided if basic_parser didn't try to dictate the number storage format and treated these the same as strings. That would allow both for arbitrary length/precision numbers to be handled as well as embedded clients that want to use 16-bit integer storage rather than 64-bit, for example. And it'd be more consistent with how keys and strings are handled. Let the class that actually does want to dictate the storage format (i.e. json::parser, which dictates use of json::value) do so, and keep that away from json::basic_parser. It just makes sense. And if anything, it should improve performance (by not doing it when not needed); I don't see why you think it'd be less efficient in an upper layer.