By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,190 Members | 1,503 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,190 IT Pros & Developers. It's quick & easy.

header file without include guard

P: n/a
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.

Oct 20 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
we*****@yahoo.com wrote:
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
Oct 20 '05 #2

P: n/a

we*****@yahoo.com wrote:
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.

Oct 20 '05 #3

P: n/a
we*****@yahoo.com wrote:
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.

Oct 20 '05 #4

P: n/a
If so, what is good for include guard?

Oct 20 '05 #5

P: n/a
ben
we*****@yahoo.com wrote:
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
Oct 20 '05 #6

P: n/a
got it, thanks.

Oct 20 '05 #7

P: n/a

wenm...@yahoo.com wrote:
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

Oct 20 '05 #8

P: n/a
In article <11**********************@o13g2000cwo.googlegroups .com>,
paulius-maruska <pa*************@gmail.com> wrote:
we*****@yahoo.com wrote:
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.


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 / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Oct 20 '05 #9

P: n/a
we*****@yahoo.com wrote:
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
Oct 20 '05 #10

P: n/a
In article <11**********************@g43g2000cwa.googlegroups .com>,
<we*****@yahoo.com> wrote:
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.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Oct 20 '05 #11

P: n/a
On 20 Oct 2005 11:14:02 -0400, co****@panix.com (Greg Comeau) wrote in
comp.lang.c++:
In article <11**********************@o13g2000cwo.googlegroups .com>,
paulius-maruska <pa*************@gmail.com> wrote:
we*****@yahoo.com wrote:
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.


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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Oct 21 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.