Re: [Jsoncpp-devel] Backwards incompatible change in jsoncpp 64-bit support

[Aaron J. <ja...@go...>]

On Tue, May 24, 2011 at 8:34 PM, Baptiste Lepilleur
<bap...@gm...> wrote:
> This is what I had in mind when I said that "isUInt() should succeed if the
> value is a positive signed int Value". I think it moves the API in the right
> direction: there should always be a way to know if a function will throw
> before calling it.

I like it. Should it be done?


> It is not too late. It should not be difficult to add a data member to
> Features instance passed to the Reader to control its behavior that would
> indicate if integer greater than 32 bits should be stored as double or int
> in the Json::Value. Feel free to add this behavior, it should not be too
> difficult.

If we choose the solution above, then this isn't really necessary,
except for strict backwards compatibility. I'll take a look and see if
it's actually necessary at Google as a case study.


> That being said, when I look back at your code sample:
>    unsigned int value =
>        value.isUInt() ? value.asUInt() :
>            (value.isDouble() ? value.asDouble() : kError);
>
> I can not help but feel that something is wrong. If value does not fit on a
> 32 bits integer, then you will get mostly a random value after conversion to
> double followed by a cast to unsigned int. Am I missing something?

Ah, good point. The real original code stored the result in int64, and
happened to know that only values less than 2^63 would be consumed as
input. The 'unsigned int' bit is an error in my transcription.

Aaron