This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
Re: Some shadow fixes.
- To: libstdc++ at sourceware dot cygnus dot com
- Subject: Re: Some shadow fixes.
- From: Nathan Myers <ncm at cantrip dot org>
- Date: Fri, 19 May 2000 02:44:54 -0700
- References: <Pine.SOL.3.91.1000519020653.27274A-100000@cse.cygnus.com>
- Reply-To: libstdc++ at sourceware dot cygnus dot com
On Fri, May 19, 2000 at 02:15:01AM -0700, Benjamin Kosnik wrote:
>
> Nathan, can you summarize the state of this patch? It seems to me that all
> the problem functions should just be declared "extern 'c'" and then they
> are good for both std:: and ::
>
> Right?
I don't think so. We probably do need inlines, but not quite the
way they were done in the patch.
> Can the patch be revised to take this into account, and to deal with the
> change from _C_Swamp -> _C_Legacy?
>
> >Note, though, that the C++ standard doesn't include the C99 extensions,
> >so any such have to be guarded with #ifdef __USE_C9X.
>
> This is an internal contradiction to the standard. It's clearly the
> intention of C++ to be a superset of C, including C9X.
Emphatically false. ISO C++ is a mostly-superset of C89.
The committee explicitly did not try to track C9X (beyond
trying to encourage them to extend compatibly), and the C
committee made no effort to remain compatible with C++ --
in some cases deliberately breaking compatibility,
apparently just for spite.
Portable standard-conforming C++ code cannot depend
on C9X features, and users need to be able to build in a
standard-conforming and -enforcing environment.
> Let's deal with
> the C9X issues the same way we deal with depricated code
> (_GLIBCPP_DEPRICATED) or issues that have been resolved after the
> standard was aproved (_GLIBCPP_RESOLVE_LIB_DEFECTS).
>
> Ie, in bits/c++config.h
>
> # _GLIBCPP_USE_C9X 1
The commercial reality is that we are probably obliged to
support a mixed C++ and C9X environment, but that doesn't
mean we should make it harder than necessary to write
portable code. Sure, everybody's POSIX these days, but
we still demand _POSIX_SOURCE to get to it.
Nathan Myers
ncm at cantrip dot org