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: Mark Mitchell <mark at codesourcery dot com>
- To: Gabriel Dos Reis <gdr at codesourcery dot com>, Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Cc: Nathan Myers <ncm-nospam at cantrip dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 22 May 2002 11:15:42 -0700
- Subject: Re: [RFC] libstdc++/6720 and libstdc++/6671
- References: <m3vg9hcq7m.fsf@merlin.nerim.net>
--On Tuesday, May 21, 2002 08:26:21 PM +0200 Gabriel Dos Reis
<gdr@codesourcery.com> wrote:
> Neil Booth <neil@daikokuya.demon.co.uk> writes:
>
>| Gabriel Dos Reis wrote:-
>|
>| > Nathan Myers <ncm-nospam@cantrip.org> writes:
>| >
>| > [...]
>| >
>| > | When you discard the solution, the problems come back.
>| >
>| > Certainly. But we should take care not to cure the symptoms and forget
>| > about the problem. Don't shoot the messenger. The real problem is
>| > elsewhere, and the <ext/xxx> is just exposing something much more
>| > deeper, and no it isn't poor naming.
>| >
>| > # include <cmath>
>| > int main()
>| > {
>| > double x = std::sin(9.8);
>| > }
>| >
>| > should not provoque compilation error just because there happens to be
>| > a file named cmath in the current directory. Cure that problem and
>| > the symptoms with go away.
>|
>| I don't agree with your solution of special-casing certain header names,
>
> It is not me who is special-casing certain header names. That special
> meaning of certain headers are built into the language. Failure to
> provide the expected meaning is failure to implement the language.
> Actually, what I'm suggesting is not an invention in the area of
> compiler builduing. Existing compilers do deliver that standard
> meaning (actually, they have integrated meaning ofthe headers).
>
> The plan for CPP for understanding standard header names is as follow:
>
> 1) if the header name <xxx> is known to be standard then it is
> searched in the appropriate directory
EDG uses some minor magic in this area. In particular,
#include <foo> // No extension!
matches either "foo.stdh" or plain "foo".
We could also do something like that; search for "foo.stdh" first, and
then, if you don't find it, fall back to "foo". It's not clear that's
better than your scheme, just different.
Gaby, does the standard actually say that:
#include <cmath>
always gets the "right" cmath?
I don't see anything that implies that. It says that their needn't
actually be a file named "cmath". It also says that you can search
however you please when you see "<xxx>". But I don't see that it
says that a conforming program can rely on "#include <cmath>" always
getting the right cmath; everything about how to find headers is
implementation-defined.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com