Re: [Rd] Standalone Mathlib, C++ and ISNAN()

From: Bill Northcott <>
Date: Thu 06 Jan 2005 - 10:14:12 EST

On 06/01/2005, at 9:12 AM, Thomas Lumley wrote:
>> It was suggested by one of the gcc people, but I could find no
>> documentation about it. The ISO C++ docs do not include isnan as a
>> symbol provided by cmath within the std namespace. I looked at the
>> gcc source code and could see no reason why it should work.
> Hmm. What *are* C++ programmers supposed to use to test for NaN,
> then? It might well not be anything in the ISO standard, just as it
> isn't in C89, but surely there is some prescribed way to do it.

I asked the same question. So far I got no response. It seems the gods of C++ dictate that a C++ header must not pollute the default name space. cmath includes math.h so it must undefine everything in math.h which is not converted into the std namespace.

I spent some time Googling on this and discovered a number of C++ maths packages that provided their own isnan type functions in the spirit of R_IsNaN. The fact that these functions were deemed useful by the package writers rather indicates to me that there is no way of doing it in a default ISO C++!

isnan on MacOS X, and presumably other systems, is a macro so that it can work with floats, doubles and long doubles unlike R_IsNan which I understand will only work with doubles. There are actualy three underlying isnan functions in libSystem: __isnanf(float), __isnand(double) and __isnan(long double).

> We don't want ISNAN to be a function unnecessarily in C, since it is
> used a lot and there is reportedly quite a bit of overhead to very
> simple functions on some processors.

I quite understand that and of course ISNAN works just great from C code. However, I do think it would be useful to provide a warning in the documentation about using ISNAN in C++ and include R_IsNaN in the standalone package as a workaround.

The current state is that our code (JAGS), which used to work with R1.9, won't build against a standalone library on MacOS X and presumably other platforms with similar header structures.

Bill Northcott

PS All this just reinforces my long held belief that C++ is thoroughly undesirable, and if I want an OO extension of C, I will stick with Objective-C which just extends C in a minimalist way without stuffing it up. mailing list Received on Thu Jan 06 10:49:33 2005

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:02:29 EST