Re: [boost] Re: is_nan

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2003-07-04 23:00:55

On Fri, 4 Jul 2003, Fernando Cacciola wrote:

> Gabriel Dos Reis <gdr_at_[hidden]> wrote in message
> news:m31xx6i7tm.fsf_at_uniton.integrable-solutions.net...
> > "jvd" <vygis_d_at_[hidden]> writes:
> >
> > | Dear boosters,
> > |
> > | seems like this code
> > |
> > |     template< typename T >
> > |     bool is_nan( const T& v )
> > |     {
> > |         return std::numeric_limits<T>::has_quiet_NaN && (v != v);
> > |     }
> > |
> > | does not work correctly on some machines.
> >
> > Yes.  It is an incorrect (unfortunately popular) implementation.
> >
> Right. We should say that more often. It is incorrect however popular.

Yes, it is incorrect for C++. But it's something we can hope to see one
day. For example, in the LIA-1 annex I about C langage bindings, it is
written that != is a binding for IEEE-754 ?<> operator (unordered
compare). In the C9X annex F.8.3 about relational operators, it is written
that the optimization "x != x -> false" is not allowed since "The
statement x != x is true if x is a NaN". And so on.

> Most compilers provide a non standard extension for this purpose.
> For instance, Borland uses _isnan.
> In general, these extensions are found on <float>.

In fact, since it is not specified by the C++ standard, isnan comes from
the C headers and is supposed to be found in <math.h>.

> The best approach, IMO, is to have a boost::is_nan() with compiler specific
> implementations.

Yes, and there also were discussions on this mailing-list about a
<boost/fenv.hpp> header. But unless somebody finds the time to tackle this
whole problem...

Regards,

Guillaume