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

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

Wow, that's crazy. I think your solution to the first problem is good.
For the second, maybe the best would be to *parse* the floating point
string to be checked, checking that it parses successfully and differs
from the original double by no more than 0.1% or whatever?

On Thu, May 26, 2011 at 5:45 PM, Baptiste Lepilleur
<bap...@gm...> wrote:
>
>
> 2011/5/25 Aaron Jacobs <ja...@go...>
>>
>> Hmm, but does it make sense to say a default constructed value is all
>> of null, an array, and an object? Wouldn't it make more sense to have
>> isArray (and only isArray) start returning true once the value is
>> "turned into" an array by appending something to it?
>>
>> I'd appreciate if you could investigate the VC++ issues; I don't have
>> easy access to a Windows machine.
>
> The unit test failures are real strange:
>    double x = kint64max;
>    double y = val.asDouble();
>    int count = 0;
>    if ( y == x ) // OK (case 1)
>    {
>        ++count;
>    }
>    if ( double(kint64max) == y ) // BAD (case 2)
>    {
>        ++count;
>    }
> Looking at the assembly, the only difference I see is that in the first case
> the x value (kint64max) is loaded from the local variable, while in the
> second case it never leave the FPU register if I understand correctly. My
> guess is that we are stumbling into the fact that FPU register have an
> internal precision of 80 bits. I'm not sure how to confirm this though...
> Case 1:
>    if ( y == x )
> 00411B97  fld         qword ptr [ebp-290h]
> 00411B9D  fcomp       qword ptr [ebp-2A0h]
> 00411BA3  fnstsw      ax
> Case 2:
>    if ( double(kint64max) == y )
> 00411BB9  call        std::numeric_limits<__int64>::max (412D60h)
> 00411BBE  mov         dword ptr [ebp-0A4Ch],eax
> 00411BC4  mov         dword ptr [ebp-0A48h],edx
> 00411BCA  fild        qword ptr [ebp-0A4Ch]
> 00411BD0  fcomp       qword ptr [ebp-2A0h]
> 00411BD6  fnstsw      ax
> I worked-around this by making code match case 1...
>
> There is another kinds of test failures that occurs related to how floating
> pointer number are represented as string. With MSVS AFAIK we always get
> three digits in the exponent. Here are some examples of failures:
> 1>* Detail of ValueTest/integers test failure:
> 1>..\..\src\test_lib_json\main.cpp(582): "1.04858e+06" == val.asString()
> 1>  Expected: '1.04858e+06'
> 1>  Actual  : '1.04858e+006'
>
> * Test E:\prg\vc\Lib\jsoncpp-trunk\test\data\test_real_09.json
>   Difference in input at line 1:
>   Expected: '.=1.9e+19'
>   Actual:   '.=1.9e+019'
> The easiest is probably to normalize floating point string before
> comparison. What do you think?
> Baptiste.