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.
______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
