This is the mail archive of the
mailing list for the libstdc++ project.
Re: [RFC] libstdc++/6720 and libstdc++/6671
- From: Nathan Myers <ncm-nospam at cantrip dot org>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 21 May 2002 08:55:31 +0000
- Subject: Re: [RFC] libstdc++/6720 and libstdc++/6671
- References: <3CE8ED6C.email@example.com>
On Mon, May 20, 2002 at 02:34:52PM +0200, Paolo Carlini wrote:
> In a nutshell, it looks like the idea of giving the ext/ extension
> headers the same name of the corresponding standard headers (e.g.,
> <algorithm> => <ext/algorithm>) was not so good after all :-(
> Probably, some confusion stems from entry 5.4 of the FAQ, which hints at
> the possibility of using -I: now this is not an option, since, when a
> standard header tries to include another standard header which has a
> corresponding extension in ext/, it ends up including the latter,
> instead of the former!!
Standard headers were once limited in what they were allowed to
sub-include. Having <algorithm> forward to to <bits/std_algorithm.h>
wasn't done just because I liked clutter. When you discard the
solution, the problems come back.
> In fact, as suggested in 6671, we could simply change the docs
> forbidding the use of -I. Alternatively, we could rename the new
> ext headers (perhaps just adding a .h, Nathan?) Finally, as far as
> hash_map, hash_set, rope and slist are involved, we could suggest
> using -idirafter instead of -I (I did so in answering 6720)
Of course it is still possible to go back to the more-disciplined
header naming scheme; the ABI would not be affected. Unfortunately,
the ABI does not allow us to improve on the poorly-named ext/ headers
I agree that changing the FAQ is/was also a good idea. It's better
to advise fixing code than to suggest ways to avoid fixing it.
ncm at cantrip dot org