On Fri, 4 Jul 2003, Fernando Cacciola wrote: > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > "jvd" <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
