This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: backward -> deprecated
- To: libstdc++ at gcc dot gnu dot org
- Subject: Re: backward -> deprecated
- From: Nathan Myers <ncm at nospam dot cantrip dot org>
- Date: Sat, 31 Mar 2001 00:21:32 -0800
- References: <200103302335.f2UNZ7w05033@fillmore.constant.com>
- Reply-To: libstdc++ at gcc dot gnu dot org
On Fri, Mar 30, 2001 at 03:35:07PM -0800, Benjamin Kosnik wrote:
>
> I move include/backward gets moved to include/deprecated. Strong feelings?
I suspect it would confuse users. Some components are specified in the
standard as deprecated (e.g. <strstream>) -- but still required, and
portable to use -- and others are more-or-less traditional, but not
mentioned in the standard (e.g. <iostream.h> and <map.h>). Since
"deprecated" is standardese, people will reasonably assume they are
all standard-but-deprecated by ISO, where in fact ISO doesn't even
mention most. Furthermore, deprecated things are specified, and
usually required, and many of these are neither.
Anyway, "deprecated" is even longer than "backward". "old" would be
ok if you really don't like "backward".
We've seen what happens when users aren't sure what's standard and
what's not. What I'd like to see is all the backward/, nonstandard,
stuff installed into a separate directory, with a compiler option
to turn off default access to it (e.g. -fno-old-headers). In later
versions the opposite option (-fold-headers) turns on access, or
people can include <old/foo.h> without. A configure option (e.g.
--enable-default-old-headers) chooses which is the default, and
the default for *that* is what changes someday.
Nathan Myers
ncm at cantrip dot org