Re: [review][json] My review

From: Gavin Lambert (boost_at_[hidden])
Date: 2020-09-23 08:17:02

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.