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

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

Zack Weinberg wrote:
> Gabriel Dos Reis wrote:
> > Neil Booth wrote:
> > | 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.
> 
> I disagree on three grounds.
> 
> 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
shouldn't then complain when system headers get confused. The correct way
to include ext/algorithm is #include <ext/algorithm> right? So it should
be the same for ext/hash_map.
There's no conflict between sys/types.h and machine/types.h, because
everyone who uses them makes sure they specify the directory, as
documented in the man pages for any functions that require those headers.
The docs should clearly specify that to make hash_map available you should
#include <ext/hash_map>
IMHO this fits the conventional use of functions and types that aren't in
the standard headers, and means you don't have to hardcode the system
include directory into your Makefile. What if you switch to a new compiler
that doesn't keep it's stdlib in e.g. /usr/include/g++-v3 ? Your Makefile
still says -I/usr/include/g++-v3/ext. By putting <ext/algorithm> you let
the compiler decide where to find its stdlib, and look for ext/algortihm
below that point.

> Nathan is correct:  This is entirely and only an issue of naming
> conventions.  If the ext/ header names can be made not to clash with
> the standard ones, well and good; if not, tell people not to use 
> -I $(prefix)/include/g++-3/ext and forget it.

Hasn't the convention for including system headers that are in
subdirectories always been to include the subdirectory name in the
#include, e.g. #include <sys/types.h> ?
If people stick to this and use <ext/hash_map> rather than adding
-I.../ext to the compilation command then there shouldn't be any problem
with any naming scheme chosen for the headers, should there?
(Hmm, i seem to remember several weeks ago I was arguing that the headers
_should_ have a .h extension, and now I'm saying there's no need to put it
back! That was for the purposes of apps identifying filetype though, not
to prevent name clashes, which I don't think is an issue)

> Note that the problem of <foo> including <bar> and getting <ext/bar>
> can be dealt with by having foo use #include "bar", which puts the
> directory containing foo at the head of the search path.  (Unless the
> user provided -I-, but once again, if they did that they meant it.)
> 
> (I hope I have correctly understood that this problem only arises when
> that -I switch is in use.  If not, please clarify.)

Me too! My understanding of it is that i's simply an issue of doing
something silly with -I

Please feel free to ignore these probably ill-informed comments, I just
felt like piping up on this one!

jon


-- 
"A scientific theory should be as simple as possible, but no simpler."
	- Albert Einstein