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: Paolo Carlini <pcarlini at unitus dot it>
- Cc: libstdc++ at gcc dot gnu dot org, Phil Edwards <pedwards at disaster dot jaj dot com>, Nathan Myers <ncm at cantrip dot org>
- Date: 20 May 2002 15:42:05 +0200
- Subject: Re: [RFC] libstdc++/6720 and libstdc++/6671
- Organization: CodeSourcery, LLC
- References: <3CE8ED6C.2060309@unitus.it>
Paolo Carlini <pcarlini@unitus.it> writes:
[...]
| 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 ans slist are involved, we could suggest using -idirafter
| instead of -I (I did so in answering 6720)
Actually, the advise to use -I. does not scale to versioned headers, so
I vote for its removal from the FAQ. Next, we have to document that
in the same way a standard header can #include any standard header, an
extension header can #include any extension header.
Where the compiler finds the extension headers should be part of its
knowledge database and (normal) users should not tell it where to find
them.
The problem you're describing is no more different than the following
scenario:
1) mdkir toto && cd toto
2) touch cmath
3) cat >> t.C <<EOF
#include <cmath>
int main()
{
double x = std::sin(9.7);
}
EOF
4) g++ -I. t.C
That is a general problem.
-- Gaby