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

[Baptiste L. <bap...@gm...>]

2011/5/24 Aaron Jacobs <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?
>

Yes I think we should go ahead. The current behavior of having the isXYZ
method returning true and asXYZ failing with an exception is certainly NOT
what a user would expect.

Looking back at the existing API, it is likely that user to code like
isInt() || isUInt() to get a positive integer as it is difficult to predict
if the value 1 is a int or uint...

Hopefully it will not break existing code, but this change can be clearly
documented in the NEWS file. There are some unit tests for the isXYZ
functions, so we will see exactly what is impacted.


> > 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.
>

OK, I though it would be something along those lines.

Baptiste.


> Aaron
>