Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Preprocessor, nested files etc.

Reply
Thread Tools

Preprocessor, nested files etc.

 
 
Denis Remezov
Guest
Posts: n/a
 
      08-12-2004
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
 
Reply With Quote
 
 
 
 
Florian
Guest
Posts: n/a
 
      08-12-2004
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.


 
Reply With Quote
 
 
 
 
Ali Cehreli
Guest
Posts: n/a
 
      08-12-2004
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
 
Reply With Quote
 
Ashes
Guest
Posts: n/a
 
      08-13-2004
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

 
Reply With Quote
 
Ashes
Guest
Posts: n/a
 
      08-13-2004
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

 
Reply With Quote
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      08-13-2004
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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Thomas Matthews
Guest
Posts: n/a
 
      08-13-2004
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

 
Reply With Quote
 
Florian
Guest
Posts: n/a
 
      08-13-2004
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
> (E-Mail Removed)



 
Reply With Quote
 
Florian
Guest
Posts: n/a
 
      08-13-2004
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" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) ...
> 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



 
Reply With Quote
 
Florian
Guest
Posts: n/a
 
      08-13-2004
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Nested friend class in nested template problem tonvandenheuvel@gmail.com C++ 3 12-07-2007 03:02 PM
dealing with nested xml within nested xml within...... Ultrus Python 3 07-09-2007 09:00 PM
Is nested class automatically friend of class that it is nested in? request@no_spam.com C++ 5 09-25-2006 08:31 AM
Nested Vector Nester Classes are Nested in my Brain Chad E. Dollins C++ 3 11-08-2005 04:46 AM
Nested iterators (well, not nested exactly...) Russ Perry Jr Java 2 08-20-2004 06:51 PM



Advertisments