This is the mail archive of the
mailing list for the GCC project.
Re: Removal of pre-ISO C++ items from include/backwards
Joe Buck <Joe.Buck@synopsys.COM> writes:
| On Wed, Oct 24, 2007 at 05:32:12PM -0700, Mark Mitchell wrote:
| > Richard Guenther wrote:
| > > 2007-10-18 Benjamin Kosnik <firstname.lastname@example.org>
| > >
| > > Removal of pre-ISO C++ items from include/backwards.
| > > * include/Makefile.am (backward_headers): Remove all but
| > > strstream,
| > > backward_warning.h.
| > > * include/Makefile.in: Regenerate.
| > > * include/backward/new.h: Remove.
| > > * include/backward/iterator.h: Same.
| > > ...
| > >
| > >
| > > I don't think this is a great idea. What is the benefit of this apart
| > > from causing endless pain? (SPEC2000 eon now fails to build for example)
| > I would like to ask the same question.
| > Once an API is present in the C++ runtime library, my feeling is that it
| > should be there forever, for very long definitions of forever. I don't
| > even think we should move headers; for example, it seems better to
| > create a new include directory to put new functionality into than to
| > move old headers out of existing include directories.
| Agreed. We shouldn't be making gratuitous changes that just complicate
| the lives of those who have to build thousands of free software packages
| into GNU/Linux or BSD distributions. Extra headers in backward don't
| hurt anything, while taking them out does.
'deprecated' in the standard does not carry much semantics weight,
unless the feature is also removed. But, even then we would have to
worry about existing codes that were written using the feature. That
is one of the reasons why I'm unsympathetic to proposals before the
committee to `deprecate' things.