jsoncpp-devel Mailing List for json-cpp

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

I've went ahead and did the "normalize exponent string" approach since
comparing double with ratio is always tricky (e.g; 0.1% of which number...).

I'm done fixing most portability issues. It now compiles and pass all tests
on:
IBM AIX on Power6 with XLC 7
Solaris X86 / Sunstudio 12
Solaris SPARC / Sunstudio 12
Windows XP SP3 / MSVS 6.6, 2003, 2005, 2008
Linux redhat 3 / gcc 3.2.3
Linux redhat5. 3 / gcc 4.1.2

There is still some failing unit tests with MSVS 2010 that I need to
investigate...


>
> 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;
> >    }
>
[...]
>

I though I would share the portability issues I run into and fixed the last
few days:

- Do not use STL API that requires special handling of 64 bits integers.
Those can lead to interesting errors (MSVC 6 is a typical example):
  My understanding is that the initial STL standard did not acknoledge the
existence of 64 bits integers and STL implementor did not extend the API on
their own...
  - std::ostream do not support 64 bits integer, leading to ambiguous
overload compilation error
  - std::numeric_limits<> compiles but returns 0 at run_time
- Do not rely on formatting of floating point numbers as string:
  MSVC typically always output 3 digits in the exponent, Unix platforms have
a varying number of digits
  (This was solved by introducing the normalizeFloatingPointStr() function
to normalize the formatting of the floating-point exponent)
- uint64 to double conversion is trouble:
  Unfortunately no generic recipes. Requires multi-platform testing when
introducing new use cases...
  - not supported by MSVC6 (worked-around by using int64 to double
conversion)
  - can run into interesting precision issues when comparing double stored
in local variable and FPU registers (that may be of greater precision)
  - some strange issue when converting uint64 max to double on the very old
XLC 7 compiler (produced -1...)
- Do not use LL and ULL for 64 bits literal
  Unfortunately not supported by all compilers (MSVC 6 for instance).
  - work-around this by converting an integer to int64. Example: UInt64(1)
<< 63

Baptiste.