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

[Bill Northcott]

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.