From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-09-16 09:28:21
MS provides these MACROS (but no the source for them):
/* IEEE recommended functions */
_CRTIMP double __cdecl _copysign (double, double);
_CRTIMP double __cdecl _chgsign (double);
_CRTIMP double __cdecl _scalb(double, long);
_CRTIMP double __cdecl _logb(double);
_CRTIMP double __cdecl _nextafter(double, double);
_CRTIMP int __cdecl _finite(double);
_CRTIMP int __cdecl _isnan(double);
_CRTIMP int __cdecl _fpclass(double);
How about other systems?
(BTW is seems a bit odd that std::numeric_limits provides a value for
quiet_NaN but no way
of using it to test if is_nan. Is this really one for the C++ Standards
> -----Original Message-----
> From: Fernando Cacciola [mailto:fcacciola_at_[hidden]]
> Sent: Thursday, September 13, 2001 7:33 PM
> To: boost_at_[hidden]
> Subject: RE: [boost] Re: Math Functions - is_nan & is_infinity
> In particular, template functions is_nan,is_inf just shortcut into the
> compiler supplied versions (most <float> headers contains this).
> With this, the problem of supplying the internal functions for a specific
> compiler/platform is isolated from user code, and support can be added per
> context as soon as we know how.
> I think that the only way around portability here is to supply the
> compiler-specific functions used here by hand in those compilers that just
> don't have it. I know this just defers the problem but isolates it very
> well from the users of the templated 'is_nan'.
> Note: this headers uses the 'method 1' as suggested by Eric Ford.
> We need to
> consider the other alternatives that he suggested.
> Fernando Cacciola
> Sierra s.r.l.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk