Preprocessor, nested files etc.

[Florian]

Hi,

I'm hoping that someone can point me into the right direction here. I'm
trying to gain a bit of a better understanding on how the preprocessor
works - something that seems like a simple topic! I just keep running into
problems (Windows platform) because files are included in the wrong order,
one include file messes up the other one etc.. I think I need to brush up on
some basics here.

In this example project, I have several cpp files (~10) that all pretty much
include one common header file. In Visual Studio I turned the option on to
actually generate those pre-processed files - so that I could see what's
actually going on behind the scenes.

Well, I expected one big file but instead got one preprocessor file for each
of the cpp files in the project. OK, I suppose that this makes sense. One of
the things however I'm constantly trying to do is to prevent header files
from being included more than once - do I not need to worry about this when
it's included from different cpp files?

Also, when I #define macros and put them at the beginning of the header file
like

#ifndef HEADERFILE1_H
#define HEADERFILE1_H

....
...
#endif

then those macro definitions don't seem to stick. When the next cpp files is
being processed, the header file is being included again - even though the
macro was previously defined

Is this normal, and where am I getting confused?
Thanks!
Flo.

[Ali Cehreli]

On Thu, 12 Aug 2004 15:17:26 -0700, Florian wrote:

I just keep running
into problems (Windows platform) because files are included in the wrong
order,
Headers should be minimal and complete. Each header should include every
header it needs. Nothing more. This would prevent users needing to know
about inclusion orders.

One cheap trick to ensure the completeness of headers is to include that
header in that headers implementation file *first*. Assume foo.h exists,
then in foo.cpp:

// foo.cpp
#include "foo.h" // before other includes

Some Windows headers were not complete (at least in the VC++ 6.0 days),
so you were forced to know some inclusion order.
one include file messes up the other one etc..
That sounds like a macro problem. One macro defined in one header
changes the text in another header. Macros are evil; try to avoid them.
One of the things however I'm constantly trying to do is to
prevent header files from being included more than once
This is needed and important for each translation unit. Each translation
unit should include each header file that it needs only once.
- do I not need
to worry about this when it's included from different cpp files?
Perfectly normal. The C++ compilation unit is called a translation
unit. A translation unit is what comes out of the
preprocessor. Translation units are not aware of other translation
units. If a cpp file needs definitions in a header, it must include that
header itself.
Also, when I #define macros and put them at the beginning of the header
file like

#ifndef HEADERFILE1_H
#define HEADERFILE1_H

...
..
#endif

then those macro definitions don't seem to stick. When the next cpp
files is being processed, the header file is being included again - even
though the macro was previously defined

Is this normal, and where am I getting confused?

This is normal.

Ali

[Ashes]

Hi

You can also use the directive, #pragma once, in the header file - this
would ensure that the header is only included once in a build.

Regards
Ashley Visagie

[Ashes]

Hi

You can also use the directive, #pragma once, to ensure that the header
file is only included once in a build.

Regards
Ashley Visagie

[Denis Remezov]

Ashes wrote:

Hi

You can also use the directive, #pragma once, in the header file - this
would ensure that the header is only included once in a build.

Strictly speaking, whatever you can do with #pragma is implementation-defined.
I'd say don't use it unless you really have to.

Though I've got to admit, every compiler that I have access to implements
#pragma once the way you would expect it. Then again, Gcc does complain
about it being "obsolete".

Denis

[Karl Heinz Buchegger]

Florian wrote:

then those macro definitions don't seem to stick. When the next cpp files is
being processed, the header file is being included again - even though the
macro was previously defined

Is this normal, and where am I getting confused?

Each source code file (each *.cpp) is compiled independently of all others.
That's the way things work in C++.
And of course it makes sense. Your project consists of 10 files. The project
I am involved in, consists of more then 400 files. Consider I make a change
in one of them and the compiler is going to recompile everything (sometimes
we have to do this, it takes around 2 hours for a complete recompile).

When the compiler compiles a *.cpp file, it starts in a fresh state. Nothing
it has learned by compiling a previous source code file remains. Which is
a good thing, because it means it can compile a collection of *.cpp files
in any order it likes. If you make a change in one of them, only this file
needs to be recompiled and the linker will form a new executable from the
results of all the copilation steps (they are called 'object files' or 'machine
code files')

--
Karl Heinz Buchegger
kb******@gascad.at

[Thomas Matthews]

Ashes wrote:

Hi

You can also use the directive, #pragma once, to ensure that the header
file is only included once in a build.

Regards
Ashley Visagie

Which compiler uses #pragma once?
The OP is working on a Windows platform. There are many
different compilers that are available for that platform.
The #pragma directives are compiler specific.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Florian]

Danke Heinz,

That makes sense now. I just didn't know that in C++ each cpp file is it's
on unit, like Ali said. Thanks a lot for clarifying this, that will make
troubleshooting a bit easier in the future.

Flo

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:41***************@gascad.at...

Florian wrote:

then those macro definitions don't seem to stick. When the next cpp files
is
being processed, the header file is being included again - even though
the
macro was previously defined

Is this normal, and where am I getting confused?

Each source code file (each *.cpp) is compiled independently of all
others.
That's the way things work in C++.
And of course it makes sense. Your project consists of 10 files. The
project
I am involved in, consists of more then 400 files. Consider I make a
change
in one of them and the compiler is going to recompile everything
(sometimes
we have to do this, it takes around 2 hours for a complete recompile).

When the compiler compiles a *.cpp file, it starts in a fresh state.
Nothing
it has learned by compiling a previous source code file remains. Which is
a good thing, because it means it can compile a collection of *.cpp files
in any order it likes. If you make a change in one of them, only this file
needs to be recompiled and the linker will form a new executable from the
results of all the copilation steps (they are called 'object files' or
'machine
code files')

--
Karl Heinz Buchegger
kb******@gascad.at

[Florian]

Thanks Ali,

That makes more sense now. I didn't know that in CPP each file was it's own
translation unit. I suppose that's not the case in C then, correct?

Anyway - thanks a bunch,

Flo.

"Ali Cehreli" <ac******@yahoo.com> wrote in message
news:pa*********************************@yahoo.com ...

On Thu, 12 Aug 2004 15:17:26 -0700, Florian wrote:

I just keep running
into problems (Windows platform) because files are included in the wrong
order,

Headers should be minimal and complete. Each header should include every
header it needs. Nothing more. This would prevent users needing to know
about inclusion orders.

One cheap trick to ensure the completeness of headers is to include that
header in that headers implementation file *first*. Assume foo.h exists,
then in foo.cpp:

// foo.cpp
#include "foo.h" // before other includes

Some Windows headers were not complete (at least in the VC++ 6.0 days),
so you were forced to know some inclusion order.

one include file messes up the other one etc..

That sounds like a macro problem. One macro defined in one header
changes the text in another header. Macros are evil; try to avoid them.

One of the things however I'm constantly trying to do is to
prevent header files from being included more than once

This is needed and important for each translation unit. Each translation
unit should include each header file that it needs only once.

- do I not need
to worry about this when it's included from different cpp files?

Perfectly normal. The C++ compilation unit is called a translation
unit. A translation unit is what comes out of the
preprocessor. Translation units are not aware of other translation
units. If a cpp file needs definitions in a header, it must include that
header itself.

Also, when I #define macros and put them at the beginning of the header
file like

#ifndef HEADERFILE1_H
#define HEADERFILE1_H

...
..
#endif

then those macro definitions don't seem to stick. When the next cpp
files is being processed, the header file is being included again - even
though the macro was previously defined

Is this normal, and where am I getting confused?

This is normal.

Ali

[Florian]

Thanks,

It seems as if my "problem" was the fact that I didn't understand the
concept of the translation units - I should be fine in the future.

Flo.

"Ashes" <av******@hotmail.com> wrote in message
news:92******************************@localhost.ta lkaboutprogramming.com...

Hi

You can also use the directive, #pragma once, in the header file - this
would ensure that the header is only included once in a build.

Regards
Ashley Visagie

[John Harrison]

"Florian" <wi*******@gmxREMOVEUPPERCASE.net> wrote in message
news:3l***************@newssvr28.news.prodigy.com. ..

Thanks Ali,

That makes more sense now. I didn't know that in CPP each file was it's own translation unit. I suppose that's not the case in C then, correct?

Not correct. C and C++ have the same compilation model.

john

[lilburne]

Florian wrote:

Thanks Ali,

That makes more sense now. I didn't know that in CPP each file was it's own
translation unit. I suppose that's not the case in C then, correct?

C source files are complied the same as C++. Each is its own translation
unit.

[Karl Heinz Buchegger]

Florian wrote:

Thanks Ali,

That makes more sense now. I didn't know that in CPP each file was it's own
translation unit. I suppose that's not the case in C then, correct?

Same thing

--
Karl Heinz Buchegger
kb******@gascad.at