|
Boost : |
From: John Maddock (john_at_[hidden])
Date: 2005-12-01 14:18:06
> To get a clean compile at level 4 with no MS extensions, I had to
> patch
>
> ios_state.ipp
>
> #if defined(_MSC_VER)
> # pragma warning( push)
> # pragma warning(disable : 4512) // assignment operator could not be
> generated.
> #endif
>
> and #pragma (pop) at the end of the module.
>
> in test_tools.ipp added static_cast<std::streamsize>( - to avoid a
> warning)
>
> m_pimpl->m_pattern.ignore(
> static_cast<std::streamsize>(m_pimpl->m_synced_string.length() - i -
> suffix_size));
That's a Boost.Test issue.
> #if defined(_MSC_VER)
> # pragma warning(disable : 4723) // Deliberate potential divide by 0!
> #endif
>
> at the top of classify.cpp - looks like you really you mean to do
> this ;-)
Yes :-)
> and
>
> #elif defined(_MSC_VER) || defined(__BORLANDC__)
> if(::_isnan(static_cast<double>(t)))
> // was if(::_isnan(t))
> // warning C4244: 'argument' : conversion from 'long double'
> to 'double', possible loss of data
> // Global isnan only REALLY works for double?
>
> // _CRTIMP __checkReturn int __cdecl _isnan(__in double _X);
>
> return FP_NAN;
> #endif
>
> Is this really right? I would expect to have to have some other code
> do deal with the long double case, not just a cast? Or are we
> relying on MS never bothering to provide a true long double, >=80 ?
> If so, a comment would be helpful.
I'm relying on the fact that a cast to a narrower or wider type will never
create or destroy a NaN: we may get underflow to zero, or overflow to
infinity, but otherwise once a NaN always a NaN :-)
> The range of NaNs will be quite quite different for longer long
> doubles?
The bits are different, but a cast won't suddenly turn a NaN into something
else.
BTW the only reason that bit of code is in there, is to guard against
optimising compilers making non-IEEE assumptions in the rest of the code
(and yes the compilers exist).
> And what about _isnan(float)? It seems to pass the test but ...
>
> as only _isnan(double) is defined - as for _nextafter :-((. (Sloth at
> MS!)
Indeed, that's why _fpclass can only be used for type double.
> But I note that you have only tested with two of the considerable
> range of possible NaN.
>
> FFFFFFFF to FF800001 and 7F800001 to 7FFFFFFF for 32 bit.
>
> FFFFFFFFFFFFFFFF to FFF0000000000001 and 7FF0000000000001 to
> 7FFFFFFFFFFFFFFF for 64-bit
>
> Exhaustive testing would be exhausting, even for 32-bit, and I am not
> sure how to portably create more test values. It's really a bit
> twiddling job for vendors.
That's the problem: there is no portably way to create NaN's with other
payloads, not even with ldexp.
> I get:
>
> Running 1 test case...
> .\classify.cpp Thu Dec 1 18:02:20 2005
> MSVC version 140050727
> FP_ZERO: 0
> FP_NORMAL: 1
> FP_INFINITE: 2
> FP_NAN: 3
> FP_SUBNORMAL: 4
> Testing type float
> Testing type double
> Testing type long double
>
> *** No errors detected
> Press any key to continue . . .
>
> Which looks fine to me.
Good, thanks.
John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk