header file without include guard

[wenmang]

Hi, all:
What will happen if header files with the exact same names but with
different contents and declared/defined without include guard reside in
the include path for the compiler?
Are these header files are included more than once? If so, is it the
lastest included file always overwrite the previous one? Is this
behavior predictable?
thanks.

 

[Victor Bazarov]

What will happen if header files with the exact same names but with
different contents and declared/defined without include guard reside in
the include path for the compiler?

Nothing. They just reside there.

Are these header files are included more than once?

Included? Who said anything about including them? Oh, you are asking if
you actually write

#include "thename.ext"

in one of your files, what would happen, right? That's compiler-specific.

> If so, is it the
lastest included file always overwrite the previous one? Is this
behavior predictable?

Within the same compiler it must be. Refer to your compiler
documentation. RTFM, IOW.

V

 

[paulius-maruska]

Hi, all:
What will happen if header files with the exact same names but with
different contents and declared/defined without include guard reside in
the include path for the compiler?
Are these header files are included more than once? If so, is it the
lastest included file always overwrite the previous one? Is this
behavior predictable?
thanks.

Only the first found file will be included. So it depends on the
compiler where it will look for a file with that name first. Usualy,
compiler looks for includes in the directories specified in INCLUDE
environment variable, in exact the same order as they are specified
there.

 

[Axter]

Hi, all:
What will happen if header files with the exact same names but with
different contents and declared/defined without include guard reside in
the include path for the compiler?
Are these header files are included more than once? If so, is it the
lastest included file always overwrite the previous one? Is this
behavior predictable?
thanks.

The compiler will only see the first header file, and not the second.
The first header file it sees should be the path that is listed first
in the include path.

 

[wenmang]

If so, what is good for include guard?

 

[ben]

Hi, all:
What will happen if header files with the exact same names but with
different contents and declared/defined without include guard reside in
the include path for the compiler?
Are these header files are included more than once? If so, is it the
lastest included file always overwrite the previous one? Is this
behavior predictable?
thanks.

Headers can't have the same name. "hello.h" and "somelibrary/hello.h"
may or may not refer to the same header.

The fact is, only one of the header will be #included and may generate
errors if "ond definition rule" is violated. So it is a good idea always
put header guard in headers.

There's no such thing as overwrite in C++. Only overloading and
specialization. Neither is (directly) related to header inclusions. If a
declaration but not a definition is repeated, it is fine. If a
definition is repeated, you get an error.

Ben

 

[wenmang]

got it, thanks.

 

[deane_gavin]

If so, what is good for include guard?

Include guards have nothing to do with a situation where two different
headers of the same name exist.

Do you know why this would be bad if you didn't use include guards?

#include "file1.h" // contains, for example,
// definition of class C
#include "file2.h" // file2.h also includes file1.h

int main()
{
...
}

Gavin Deane

 

[Victor Bazarov]

If so, what is good for include guard?

They are called "*double* inclusion guards". If I include another header
that includes this one _again_, I won't get redefinitions of everything
and therefore the compilation will proceed normally.

V

 

[Greg Comeau]

Only the first found file will be included. So it depends on the
compiler where it will look for a file with that name first. Usualy,
compiler looks for includes in the directories specified in INCLUDE
environment variable, in exact the same order as they are specified
there.

It is not tue that only the first found file will be include'd
(see Victor's respoonse). It's also not the case that usually
the path chosen are taken from the INCLUDE environment variable;
some do, but this is completely compiler specific, and most include
other choices too even if they do use INCLUDE.

 

[Greg Comeau]

What will happen if header files with the exact same names but with
different contents and declared/defined without include guard reside in
the include path for the compiler?

It's implementation defined.

This can happen _for instance_ if you are using two 3rd party libs
and they both end up having some common functionality and end up
with the same name, obviously in different locations.

Are these header files are included more than once? If so, is it the
lastest included file always overwrite the previous one? Is this
behavior predictable?

Again, it's implementation-defined.

Probably in the end though, you want to have different names just
to avoid this kind of situation if you have any control over it.

 

[Jack Klein]

It is not tue that only the first found file will be include'd
(see Victor's respoonse). It's also not the case that usually
the path chosen are taken from the INCLUDE environment variable;
some do, but this is completely compiler specific, and most include
other choices too even if they do use INCLUDE.

I think you are wiggling a little bit too much on this one. A
compiler that included more than one file would be completely
non-conforming, since the standard says "the header" and "the source
file".

There is nothing that requires that an implementation select the first
matching header or file it finds in the implementation-defined search,
it could search the relevant space and use the last matching file or
header. If there is more than one matching header or file to be
found, it could arbitrarily select among them randomly or based on
some unspecified criteria.

The only thing the standard will not allow it to do is directly
include more than one header or file because of one #include
directive.