Boost logo

Boost :

From: Hadriel Kaplan (hadrielk_at_[hidden])
Date: 2020-09-26 14:39:00


> On Sep 26, 2020, at 8:37 AM, Mathias Gaunard via Boost <boost_at_[hidden]> wrote:
>
> On Fri, 25 Sep 2020 at 23:55, Vinnie Falco via Boost
> <boost_at_[hidden]> wrote:
>>
>> So, I think at some point I will want to introduce options for
>> serialization, and one of the options could be the treatment of
>> integers outside the range ~+/-2^53. We could:
>>
>> 1. serialize them as-is (current implementation)
>> 2. serialize them as the nearest representable IEEE double
>> 3. throw an exception
>>
>> I know some people might find #3 weird, I'm open to feedback.
>
> What's the problem with storing it as a string or as an arbitrary
> number when it's not representable as int64 or a double?
> It doesn't cost anything to do this, it's a pure extension with no
> impact on people that don't need it.

Do you mean encoding `int64_t`/`uint64_t` into JSON as a string, when either: (a) their value otherwise lose precision or even just (b) always?

Let’s call those options #4a and #4b. Obviously they can’t be default behavior because they don't round-trip.

#4a seems inconsistent behavior to me, but :shrug:
#4b seems reasonable, as it’s a common choice people seem to make to keep precision today.

-hadriel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk