John Nagle wrote:
>    Comments?

What if you have *different* headers with same name?
E.g.:

/usr/include:
 foo.h
/usr/include/bar:
 foo.h
/usr/include/baz:
 foo.h

Of course all three foo.h are different from each other.
Now
#include "foo.h" should find /usr/include/foo.h i assume?
but what if there is no /usr/include/foo.h, but only two
others.. if user will not specify which one to use, what
compiler is supposed to do? throw an error? I think it is
bad idea.. the same thing you may introduce into such
structure:

// don't laugh at the code it is meant to be short :)
class bar
{
 public:
  int a;
};

class baz
{
 public:
  int a;
};

class foo : public bar, baz
{
 int a;
};

or even:

class foo:
{
 bar r;
 baz z;
 int a;
};

What do you think :: operator is introduced for?

--
Best regards from
Kamil Burzynski
Advanced Digital Broadcast Poland, LTD.
 - -
It's clever, but is it art?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle wrote:
>
>     It's time for C++ to search subdirectories for include
> files. ...

It's already legal for an implementation to do that.

> ... And it's thus time to deprecate pathnames in include
> files.  Thus,

Keep in mind that the C++ standard very deliberately avoids any mention
of directories. That's outside the intended scope of the standard. It's
intended that C++ be implementable even on systems which organize their
file systems in ways that can't be mapped onto the concept of
directories (though offhand, I can't think of any). The organization of
the file system is an area for operating system standards, not language
standards. In the unlikely case that the C++ standard does start
mentioning directories, it should go all the way: adding functions for
searching them, creating them, specifying ways to determine whether a
given pathname identifies a directory or a file, etc. Unnecessarily
duplicating the current POSIX specifications would probably be the least
unwise way of doing this.

The purpose of deprecation is to allow for removal of a feature in some
future release of the standard. The ultimate removal of this feature
would break a lot of code that conforms to current POSIX specifications.
You'll need to make a decent argument for this being a problem, to
justify that. You've described various features of the way Unix/Windows
implementations typically work, and say they shouldn't work that way.
You haven't explained very clearly why you feel that way.

....
> In the early days of UNIX, file systems were slow and
> caches were small, so searching a whole directory subtree
> would slow compilation substantially.  Today, with
> megabytes of cache space, that's a nonissue.  If you're doing
> a big build, the whole directory subtree will be in memory.

Flexibility, not memory space, is the main reason for the current
approach.

....
>     This will probably be dismissed as an "implementation
> issue", but as it affects the source text of programs,
> it's not out of reach of the standard.

Yes, it is currently an implementation-dependent issue. Yes, it is
outside the reach (scope) of the current standard. However, whether the
scope of the standard should be extended to compete and interfere with
operating system standards, by specifying details about the file system
organization, is an appropriate topic for this forum. My answer is "no".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle:
>     It's time for C++ to search subdirectories for include
> files.  And it's thus time to deprecate pathnames in include
> files.  Thus,
>
> #include "bar"
>
> finds "bar" anywhere in the directories being considered
> for input.  Constructs like
>
> #include "foo/bar"
>
> should be interpreted as restricting the search path.  But
> anything "foo/bar" will find, "bar" will find.
>
>      The basic idea is to get rid of includes like
>
> #include "foo/bar/baz/alt.h"
>
> and avoid directory structure dependency issues.

Maybe this is a silly question, but here goes: if you
want this behaviour why don't you just put all your
include files in one directory?

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

John Nagle wrote:
>=20
>     It's time for C++ to search subdirectories for include
> files.  And it's thus time to deprecate pathnames in include
> files.  Thus,
>=20
>         #include "bar"
>=20
> finds "bar" anywhere in the directories being considered
> for input.  Constructs like
>=20
[..]

>     I'd argue that finding the same include file twice in
> the same subtree should be considered an error.  Otherwise,
> order of search matters, which leads to strange bugs.
>=20

I believe this is the main flaw in your proposal : It would require
every vendor of every library to have unique names for their headers,
and that would lead to include files named "vendor1_version.h " and
"vendor2_version.h".
I believe the situation would then be worse than it is currently.

--=20
Lo=EFc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

nopik@kamilb.adb.pl wrote:
>
> John Nagle wrote:
> >    Comments?
>
> What if you have *different* headers with same name?
> E.g.:
>
> /usr/include:
>         foo.h
> /usr/include/bar:
>         foo.h
> /usr/include/baz:
>         foo.h
> Of course all three foo.h are different from each other.
> Now
> #include "foo.h" should find /usr/include/foo.h i assume?
> but what if there is no /usr/include/foo.h, but only two
> others.. if user will not specify which one to use, what
> compiler is supposed to do? throw an error? ...


Yes, that's precisely what he said should happen.

> ... I think it is
> bad idea. ...

I agree.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Lo=EFc Joly wrote:

> John Nagle wrote:
>=20
>>    It's time for C++ to search subdirectories for include
>>files.=20



> I believe this is the main flaw in your proposal : It would require
> every vendor of every library to have unique names for their headers,
> and that would lead to include files named "vendor1_version.h " and
> "vendor2_version.h".
> I believe the situation would then be worse than it is currently.


     Actually, it would make it more like where Perl is now.

     Perl, though, looks for modules, not files.  Perl
modules have names like "HTML::Element".  It doesn't matter
where it it, but the full name does matter.

     But it's too big a change for C++.  D, maybe.

     John Nagle


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

    It's time for C++ to search subdirectories for include
files.  And it's thus time to deprecate pathnames in include
files.  Thus,

 #include "bar"

finds "bar" anywhere in the directories being considered
for input.  Constructs like

 #include "foo/bar"

should be interpreted as restricting the search path.  But
anything "foo/bar" will find, "bar" will find.

     The basic idea is to get rid of includes like

 #include "foo/bar/baz/alt.h"

and avoid directory structure dependency issues.

     Perl has done this for some years now, and
Perl, being an interpreter, has to search every time the
program runs.  So it's clearly not a performance issue
for hard-code compilers like C++.
In the early days of UNIX, file systems were slow and
caches were small, so searching a whole directory subtree
would slow compilation substantially.  Today, with
megabytes of cache space, that's a nonissue.  If you're doing
a big build, the whole directory subtree will be in memory.

    I'd argue that finding the same include file twice in
the same subtree should be considered an error.  Otherwise,
order of search matters, which leads to strange bugs.

    The list of subtrees to be searched is an implementation
related issue; it would presumably be a command-line flag
in command-line systems, and something in the project
database for more advanced build models.

    This will probably be dismissed as an "implementation
issue", but as it affects the source text of programs,
it's not out of reach of the standard.

    Comments?

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]