In article <9514102.2925@mulga.cs.mu.OZ.AU> fjh@mundil.cs.mu.OZ.AU (Fergus Henderson) writes:

[Regarding which directories get searched in #include directives when
the directives are contained in header files that are, themselves,
included by files in other directories.]

>
> I agree with RFG that it is a pity this area has not been standardized.

I do too.  On the other hand, I can understand why it hasn't been
standardized: anything that has to deal with file names and
directories just can't possibly be portable.  What would you do about
VMS, whose syntax for specifying directories is very different from
Unix's, and what would you do with operating systems that have flat
filesystems?  It would be very difficult to come up with wording that
both was useful and that didn't make too many assumptions about the
operating system.

I agree that Borland's behavior is clearly wrong ("an implementation
must not only be standard-conforming but also useful"), so I'm in the
uncomfortable position of saying that there is one correct form of
behavior but that that behavior probably shouldn't be specified in the
standard.  I have trouble seeing a way out of that dilemna, though.

--
Matt Austern          matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

Miles B. Whitener <mbw@surface.com> wrote:

>If I have two header files, a.h and b.h, and they are both
>in ../../Common/ (relative to my .C or .cpp file), and I want to include
>b.h from a.h, should a.h say
>  #include "b.h"
>or should it say
>  #include "../../Common/b.h"
>?
>
>Borland 4.02 seems to require the latter, which seems insane, while
>MS 2.1a likes the former, which seems correct to me.  But my
>code has to compile under both and I just wish they agreed.

I agree that the latter is somewhat insane, since the relative path
depends on the location of the file you are compiling.
However, another alternative is to say

 #include "Common/b.h"

and compile with "-I ../..".  This alternative has the advantage that
you only need one "-I" option for each package you are using, and
the #include lines remain constant no matter which directory you
are compiling from - only the -I option need change.

I agree with RFG that it is a pity this area has not been standardized.

--
Fergus Henderson                       | I'll forgive even GNU emacs as
fjh@cs.mu.oz.au                        | long as gcc is available ;-)
http://www.cs.mu.oz.au/~fjh            |             - Linus Torvalds

In article <527cb$10181a.1ab@rd.surface.com>,
Miles B. Whitener <mbw@surface.com> wrote:
>  Thanks to everybody who replied.  Sorry for the bogus return address.
>  I did not make it clear that I consider -I to be insufficient here.
>With -I, we are really considering the include file name space (the
>part of it specified after -I) to be flat -- if I have two files in
>different paths with the same name, I could accidentally include the
>wrong one.  Also, I can't specify which path I want except the single
>path list applied to the .C(pp) file -- it's hard to make
>a .h file simply include other .h files that it depends upon, that live
>in the same directory as itself (without using -I).
>  That is not really good.  The way MS C(++) works provides nicely
>for large subtrees of include files that include other files.  I can't
>believe Borland can't do it too.  Is this a place  where good old
>idealistic Borland has towed the standards line to my (and others')
>detriment?

No.  Sadly, there is no ``standard'' way of processing the filenames in
#include directives... except for the de facto standard followed by most
of the available C and C++ compilers.

I'v pointed out this problem with the Borland compiler(s) here before,
and asked how many other compilers handle #include directives in the
weird way that Borland does.  I think that the responses indicated that
only DEC's C compiler for VMS behaves in this same strange way with respect
to #include directives.  All other known C/C++ compilers process #include
directives the way you want (and the way that most of us expect).

I do wish that Borland would fix this.

>I know how to make this work -- but it is gross, messy
>and compiler-specific.  I *must* be missing something!
>
>In article <41d7cb$03325.3a@rd.surface.com>, mbw@surface () says:
>>
>>  If I have two header files, a.h and b.h, and they are both
>>in ../../Common/ (relative to my .C or .cpp file), and I want to include
>>b.h from a.h, should a.h say
>>  #include "b.h"
>>or should it say
>>  #include "../../Common/b.h"
>>?
>>
>> Borland 4.02 seems to require the latter, which seems insane, while
>>MS 2.1a likes the former, which seems correct to me.  But my
>>code has to compile under both and I just wish they agreed.
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

  Thanks to everybody who replied.  Sorry for the bogus return address.
  I did not make it clear that I consider -I to be insufficient here.
With -I, we are really considering the include file name space (the
part of it specified after -I) to be flat -- if I have two files in
different paths with the same name, I could accidentally include the
wrong one.  Also, I can't specify which path I want except the single
path list applied to the .C(pp) file -- it's hard to make
a .h file simply include other .h files that it depends upon, that live
in the same directory as itself (without using -I).
  That is not really good.  The way MS C(++) works provides nicely
for large subtrees of include files that include other files.  I can't
believe Borland can't do it too.  Is this a place  where good old
idealistic Borland has towed the standards line to my (and others')
detriment?  I know how to make this work -- but it is gross, messy
and compiler-specific.  I *must* be missing something!

In article <41d7cb$03325.3a@rd.surface.com>, mbw@surface () says:
>
>  If I have two header files, a.h and b.h, and they are both
>in ../../Common/ (relative to my .C or .cpp file), and I want to include
>b.h from a.h, should a.h say
>  #include "b.h"
>or should it say
>  #include "../../Common/b.h"
>?
>
> Borland 4.02 seems to require the latter, which seems insane, while
>MS 2.1a likes the former, which seems correct to me.  But my
>code has to compile under both and I just wish they agreed.
>

In <41d7cb$03325.3a@rd.surface.com>, mbw@surface () writes:
>  If I have two header files, a.h and b.h, and they are both
>in ../../Common/ (relative to my .C or .cpp file), and I want to include
>b.h from a.h, should a.h say
>  #include "b.h"
>or should it say
>  #include "../../Common/b.h"
>?
>
> Borland 4.02 seems to require the latter, which seems insane, while
>MS 2.1a likes the former, which seems correct to me.  But my
>code has to compile under both and I just wish they agreed.

    Borland has no such requirement as long as you specify include path options.

In article <41d7cb$03325.3a@rd.surface.com> mbw@surface () writes:

> Newsgroups: comp.std.c++
> From: mbw@surface ()
> Date: Sat, 29 Apr 1995 06:51:37 GMT
>
>   If I have two header files, a.h and b.h, and they are both
> in ../../Common/ (relative to my .C or .cpp file), and I want to include
> b.h from a.h, should a.h say
>   #include "b.h"
> or should it say
>   #include "../../Common/b.h"
> ?
>
>  Borland 4.02 seems to require the latter, which seems insane, while
> MS 2.1a likes the former, which seems correct to me.  But my
> code has to compile under both and I just wish they agreed.
>
As a practical matter, you can do either, but there are
some stylistic considerations here.  In fact, there are two
points to consider, and of course they give opposite answers.

For large projects, I find it convenient if the #include statement gives
some clue about where to find the header file.  This suggests
 #include "Common/b.h"
I would put the ../.. part on the compiler command line.

On the other hand, if you move a header file to another directory,
then every source file that includes it must change.  Also, the
syntax of file paths is not universal; maybe you will have to port
the application to a system that didn't understand x/y/z pathnames.
So some say that you should never have directory information on the
include line, but should only say
 #include "b.h"
My personal view is not to listen to those people, because:
 I hate searching for header files
 I seldom have to move header files.
 I don't care about porting to those systems.

Kevin Cline

--
Kevin Cline

mbw@surface () writes:

>  If I have two header files, a.h and b.h, and they are both
>in ../../Common/ (relative to my .C or .cpp file), and I want to include
>b.h from a.h, should a.h say
>  #include "b.h"
>or should it say
>  #include "../../Common/b.h"
>?

> Borland 4.02 seems to require the latter, which seems insane, while
>MS 2.1a likes the former, which seems correct to me.  But my
>code has to compile under both and I just wish they agreed.

This situation is not covered by the C or C++ language standards,
because they do not address file system issues. There are two
common methods for searching for an included file, both allowed
by the language definition:

1. Look in the directory in which the including file was found (a.h
    in your example).

2. Look in the directory in which the "top-level" file was found
    (the .C file).

You should be able to fix the problem by adding
the "Common" directory to the list of directories to be searched, or
by just using "../../Common/b.h" consistently.

I think both solutions will work with both compilers.

--
Steve Clamage, stephen.clamage@eng.sun.com

  If I have two header files, a.h and b.h, and they are both
in ../../Common/ (relative to my .C or .cpp file), and I want to include
b.h from a.h, should a.h say
  #include "b.h"
or should it say
  #include "../../Common/b.h"
?

 Borland 4.02 seems to require the latter, which seems insane, while
MS 2.1a likes the former, which seems correct to me.  But my
code has to compile under both and I just wish they agreed.