This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/6671: ext search path
- From: paolo at gcc dot gnu dot org
- To: gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, morandini at aero dot polimi dot it, nobody at gcc dot gnu dot org
- Date: 19 May 2002 15:48:30 -0000
- Subject: Re: libstdc++/6671: ext search path
- Reply-to: paolo at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, morandini at aero dot polimi dot it, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: ext search path
State-Changed-From-To: open->analyzed
State-Changed-By: paolo
State-Changed-When: Sun May 19 08:48:29 2002
State-Changed-Why:
Hi.
I see two issues here:
1- If all is needed is a shorter access to the old STL extensions (those exisiting in ext when the doc you mention was written, i.e., hash_map, hash_set, rope, slist) then the solution is simply using -idirafter instead of -I (see libstdc++/6720). This allows to write safely <hash_map> (and still <iostream>, of course, as in your testcase).
2- OTOH, in this case <ext/memory>, f.i., must still be written in full in order to disambiguate it from <memory>.
In order to solve the latter problem, the only solution I see is renaming the new extension bits to something different.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6671