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: Gabriel Dos Reis <gdr at codesourcery dot com>
- 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: 22 May 2002 21:42:26 +0200
- Subject: Re: [RFC] libstdc++/6720 and libstdc++/6671
- Organization: CodeSourcery, LLC
- References: <20020522061245.GA1812@codesourcery.com> <20020522112816.A47392@compsoc.man.ac.uk>
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
| > 1. Good software does not second-guess the user. If the user has
| > specified -I. or -I/usr/include/g++-3/ext or whatever, they bloody
| > well meant it, for good or ill. You can think of -I. as invoking a
| > non-conforming mode of the compiler if it makes you feel better.
|
| I agree with this. If you put system header dirs in your include path
| with -I/usr/include/g++-v3/ext (or whatever) that's your lookout, you
I think you're missing the point.
Just give it one more thought: We (implemtors or users) do not always
control the files or directory that happens to be in the include path
-- and the -I{prefix}/g++-v3/ext is just a symptom of a latent bug we
failed to handle correctly.
If the user does want to replace a standard header, then he/she should
be given a chance to say so explicitly. We shouldn't be intrepreting an
accidental coincidence as expected whishes. In the same was, the
standard tries hard to insulate its entities in dedicated namespace so
that they don't accidentaly conflict with user defined ones.
-- Gaby