jsoncpp-devel Mailing List for json-cpp

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.

On Wed, May 25, 2011 at 10:52 PM, Aaron Jacobs <ja...@go...> wrote:

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

In JS, default-constructed values are 'undefined', not null:

[stephan@cheyenne:~/tmp]$ js
Rhino 1.7 release 2 2010 11 17
js> var x; print(typeof x);
undefined

(And (typeof null) == object, for some brain-dead reason or other.)

IMO that is the proper default-construction semantics. The further a JSON
impl deviates from basic JS behaviours, the less portable it is likely to
become.


isArray (and only isArray) start returning true once the value is
> "turned into" an array by appending something to it?
>

Using JS as a baseline:

js> x[1] = 3;
js: "<stdin>", line 3: uncaught JavaScript runtime exception: TypeError:
Cannot set property "1.0" of undefined to "3"
at <stdin>:3

that's the behaviour most would expect, i think (as opposed to automatic
promotion to an Array or Object).

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/

2011/5/25 Stephan Beal <sg...@go...>

> On Wed, May 25, 2011 at 4:56 PM, Baptiste Lepilleur <
> bap...@gm...> wrote:
>
>>
>>> This is that feature that allows the following usage:
>>
>> Json::Value array;
>> array.append( 1234 );
>>
>
> That means a null value is effectively mutable, and only arrays/objects are
> mutable in JS (JSON doesn't describe mutability, and it has no operators
> which would allow mutation).
>

The Json::Value is mutable and provides and operator = (Json::Value is not
supposed to be dynamically allocated). There is a Json::Value::null
constant, but its usage is not enforced at the current time.


>
> Maybe we should introduce a distinction between "default" initialization
>> and "null", but I'm not sure how to go about that...
>>
>
> Absolutely. In the 2 JSON libs i've implemented (one in C++, one in C), the
> following values all have a corresponding static/constant Value instance
> (mainly as a memory allocation optimization):
>

The cost of creating a Json::Value instance is fairly small since for all
types with the exception of string/array/object it is just an enum and
primitive type assignment. Json::Value is just a wrapper on top of a
discriminated union.


> [...]
>
> A default-constructed Value has the undefined value:
>
> Value v; // v.isUndef() will return true
> v = Object(); // now v.isObject() will return true
>

This is something that we will need to investigate in the future. I think
that making the distinction between default construction and null value make
sense. But at the current I want to focus on making sure that 64 bits
integer support is in good shape before making other API changes.

Thanks for you feedback, it's interesting to see what other API are around
there.

Baptiste.

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.

Okay, in revision 224 I've further reworked the type system to act as follows:

 *  isFoo methods determine exact representability.
 *  asFoo methods cause casting when safe.
 *  isConvertibleTo indicates whether casting is safe.

(See NEWS.txt for more details.) I think this makes isConvertibleTo fit in
with the new system properly. I had for example found code at Google that
looks like this:

    int ConvertValueToInt(const Json::Value& v) {
      if (v.isConvertibleTo(Json::intValue)) {
        return v.asInt();
      }
      else { ...}
    }

That caused problems with my last attempt because asInt() would chuck an
exception if the value was 3.5, for example. Now I've restored the behavior of
casting when requested.

The remaining rough edge is 64-bit integers -- it would break existing code to
introduce a new ValueType enum value for them, and given the code above we
can't have `Value(1LL<<40).isConvertibleTo(intValue)` return true. So as of
now, `isConvertibleTo(intValue)` may return false even if the value's type is
intValue. (See NEWS.txt for a better explanation.)