This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] libstdc++/6720 and libstdc++/6671


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]