This is the mail archive of the
mailing list for the libstdc++ project.
Re: namespace issues with old C headers
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: das at freebsd dot org
- Date: Mon, 14 Apr 2003 19:49:40 -0500 (CDT)
- Subject: Re: namespace issues with old C headers
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <20030401112627.GA58054@HAL9000.homeunix.com>
> I agree that none of my proposals were perfect; that is why I
> posted three of them. Is Loren working on a patch other than the
> one he mentioned in this thread?
The patches I'm currently working on relate to system header name
visibility (i.e. as keyed off well-known, sometimes standard-defined,
macros) and mirroring same as best as possible in libstdc++-v3 for all
ports (my main port of interest is *-*-freebsd* but I'm trying for a
Agreed, I don't think I'm solving the C99 / C++98 conflict issue under
discussion in this thread. I think practical concerns are what drove
us to attempt to support as much of C99 as possible in libstdc++-v3
even if not encouraged by C++98. If there are cases where a program
can't use the classic headers along with C++ headers, then IMHO it is
the job of our C++ library implementation to address the conflict.
The current remapping of C99 macros, which are unaddressed by C++98,
into std:: isn't driven by any standard.
Also, David, I'm confused. Could you repost an exact test case that
now fails. g++ with libstdc++-v3 built on ref5/beast after you
updated C99 stuff in the system headers appears to handle:
using namespace std;
double a = 0.0;
double b = NAN;
double c = 1.0;
if (FP_ZERO != fpclassify (a)) abort ();
if (FP_NAN != fpclassify (b)) abort ();
if (FP_NORMAL != fpclassify (c)) abort ();
For the moment, users attempting to compile code at the confluence of
C99 and C++98, will have to deal with adding the 'using namespace std'
or 'using std::fpclassify'.