This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] libstdc++/6720 and libstdc++/6671
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: Jonathan Wakely <cow at compsoc dot man dot ac dot uk>
- Cc: Zack Weinberg <zack at codesourcery dot com>, libstdc++ at gcc dot gnu dot org
- Date: Wed, 22 May 2002 19:58:27 +0200
- Subject: Re: [RFC] libstdc++/6720 and libstdc++/6671
- References: <3CEBD5BA.10409@unitus.it> <20020522185600.A63724@compsoc.man.ac.uk>
Jonathan Wakely wrote:
>On Wed, May 22, 2002 at 07:30:34PM +0200, Paolo Carlini wrote:
>
>>>ext/algorithm includes <algorithm>
>>>If this is changed to include "algorithm" will the preprocessor include
>>>ext/algorithm from the current dir, or spot that that's the current file
>>>and then proceed to look in the system dirs, finding the intended header?
>>>
>>>
>>Sorry, now I get your point, but this could easily be solved by including
>>"../algorithm", do you agree?
>>
>>
>Mmm, looks ok (but what do I know!)
>But what if there's a later sub-dir of ext, say ext/unstable,
>
Not going to happen in the near future, to my best knowledge!
>and a file
>fnord.h in there includes <algorithm>. If the user has -I${...}/ext then
>ext/unstable/fnord.h would find ext/algorithm, not algorithm.
>This could be solved by making fnord.h include "../../algorthim", but
>then you're hardcoding the directory structure into the headers and they
>could become even more fragile and vulnerable to unforeseen problems.
>
In principle, I agree, but see above.
>I still reckon it's simplest to ban -I.../ext
>
This we have /already/ done! (see Phil's recent commit). But,
nonetheless, since it costs nothing, we can implement Zack's idea anyway...
Paolo.