RE: [boost] Re: Math Functions - is_nan & is_infinity

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-09-16 09:28:21

MS provides these MACROS (but no the source for them):

float.h

/* 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
group?)

Paul

> -----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.
> fcacciola_at_[hidden]
> www.gosierra.com