This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: C++ header file problem - is this a bug?
- From: Matt Austern <austern at apple dot com>
- To: Bill Northcott <w dot northcott at unsw dot edu dot au>
- Cc: 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:36: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>
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
the C
library functions and headers, since they're for a different
programming
language.
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
following:
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++ program?
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
nothing.
I've hesitated to fix this behavior on Darwin because I've never seen a
specification or documentation of what behavior we're trying to have,
but I'm pretty sure it's not what we've got.
--Matt