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.