[Rd] Standalone Mathlib, C++ and ISNAN()
w.northcott at unsw.edu.au
Thu Jan 6 00:14:12 CET 2005
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.
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
More information about the R-devel