This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: __cplusplus revisited (on Solaris 8)
- To: bkoz at redhat dot com
- Subject: Re: __cplusplus revisited (on Solaris 8)
- From: stephen dot webb at cybersafe dot com
- Date: Fri, 23 Feb 2001 13:49:53 -0500
- Cc: libstdc++ at gcc dot gnu dot org
- Organization: CyberSafe
- References: <Pine.SOL.3.91.1010223100131.205B-100000@taarna.cygnus.com>
On Fri, 23 Feb 2001, Benjamin Kosnik wrote:
> > The Sun WS6 compiler supplies its own standard C++ header files which do nothing but include the /usr/include/iso
> > header files directly.
>
> This is what the include/c headers were supposed to do. They might not be
> in the correct form at the moment to be useful though.
I understand what you were trying to do with the include/c headers, but it will never work in their current form
with a compliant implementation. They simply include the deprecated C headers. Annex D section 1.5.2 of the C++
standard says:
2 Each C header, whose name has the form name.h, behaves as if each name
placed in the Standard library namespace by the corresponding cname
header is also placed within the namespace scope of the namespace std
and is followed by an explicit using-declaration (_namespace.udecl_)
That means just passing the contents of these headers through as-is will introduce name conflicts and defeat the
entire purpose of putting the <c..> headers in the std namespace. The only way they would work is if the C headers
put everything in namespace std and only there.
> ...or this. Perhaps you are right, we need a fourth. (Please use the
> nnaming conventions in the c_shadow directory though for the namespaces) If
> these solaris headers are in fact correct, then doing this should be relatively
> painless, and your problems are indicative of v3 trying to smash a square
> peg into a round hole. Let's not do that.
>
> Can you work up this last (Option/Solution 4) and see if that solves this
> insanity?
I think the include/c headers should be modified to filter out everything not already in the std namespace. That
way, they should work under the Solaris 8 circumstances and continue to provide the same functionality they currently
do. This would have the effect of rolling "option 4" into "option 1".
I can certainly work this up. Unfortunately I seem to have discovered a possible bug in the compiler that seems to
prevent certain key header files from being wrapped in a namespace, so any results will have to wait until that issue
is resolved.
Stephen M. Webb