This is the mail archive of the
mailing list for the libstdc++ project.
Re: C++ header file problem - is this a bug?
- From: Matt Austern <austern at apple dot com>
- To: Matt Austern <austern at apple dot com>
- Cc: Bill Northcott <w dot northcott at unsw dot edu dot au>, Dave Korn <dave dot korn at artimi dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>, gcc at gcc dot gnu dot org, JAGS <jags at iarc dot fr>, libstdc++ at gcc dot gnu dot org
- Date: Mon, 10 Jan 2005 12:55:23 -0800
- Subject: Re: C++ header file problem - is this a bug?
- References: <NUTMEG8fBPaMkYwEoNc00000c22@NUTMEG.CAM.ARTIMI.COM> <51BC97D0-5EDE-11D9-97FA-000393D3D676@unsw.edu.au> <054C70C7-2171-42B1-98CA-927C90EA8EC0@apple.com>
On Jan 10, 2005, at 12:36 PM, Matt Austern wrote:
On Jan 4, 2005, at 9:54 PM, Bill Northcott wrote:
On 05/01/2005, at 6:27 AM, Dave Korn wrote:
Did you notice that you're writing C++, and ***NOT*** C?
As such, you should use the C++ library functions and headers, not
library functions and headers, since they're for a different
Why aren't you using the std::isnan() function?
I can't find any documentation, and if I try to use it I get the
error: `isnan' undeclared in namespace `std'
which is unsurprising since it does not appear to be declared or
defined in any header in /usr/include except math.h, which gets
stuffed by cmath.
Would those be adequate reasons not to use it?
Just how is one expected to get isnan() functionality in a C++
I'm not so sure our current behavior is correct either.
First, I don't understand the motivation for undefining isnan as a
macro and then defining an std::isnan within namespace std. Yes, it's
true that defining an isnan macro would violate the C++ standard. But
then, defining an isnan function within namespace std violates the
standard too. Why go to all this effort merely to change one kind of
standard violation into another kind?
Second, as Bill has pointed out, we're not doing this completely. At
least on Darwin, we're undefining that macro and replacing it with
Sorry, I wrote this without testing---always a mistake.
As of 4.0 we're doing something on Darwin that's not so hard to
understand: the <math.h> form keeps the C99 macros from the system
headers, and the <cmath> form gets rid of those macros and replaces
them with a function template.
I'm not sure whether it was intended for isnan to be so different in
<math.h> and <cmath> (I still haven't seen a specification for how
we're trying to treat the C99 math macros), but what we're doing seems
reasonably sane and defensible to me.