Boost logo

Boost :

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.

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