Preprocessor, nested files etc.

Discussion in 'C++' started by Denis Remezov, Aug 12, 2004.

  1. 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
     
    Denis Remezov, Aug 12, 2004
    #1
    1. Advertising

  2. Denis Remezov

    Florian Guest

    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.
     
    Florian, Aug 12, 2004
    #2
    1. Advertising

  3. Denis Remezov

    Ali Cehreli Guest

    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
     
    Ali Cehreli, Aug 13, 2004
    #3
  4. Denis Remezov

    Ashes Guest

    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, Aug 13, 2004
    #4
  5. Denis Remezov

    Ashes Guest

    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
     
    Ashes, Aug 13, 2004
    #5
  6. 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
     
    Karl Heinz Buchegger, Aug 13, 2004
    #6
  7. 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
     
    Thomas Matthews, Aug 13, 2004
    #7
  8. Denis Remezov

    Florian Guest

    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" <> wrote in message
    news:...
    > 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
    >
     
    Florian, Aug 13, 2004
    #8
  9. Denis Remezov

    Florian Guest

    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" <> wrote in message
    news:p...
    > 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, Aug 13, 2004
    #9
  10. Denis Remezov

    Florian Guest

    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" <> wrote in message
    news:...
    > 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
    >
     
    Florian, Aug 13, 2004
    #10
  11. Denis Remezov

    lilburne Guest

    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.
     
    lilburne, Aug 13, 2004
    #11
  12. "Florian" <> wrote in message
    news:3l4Tc.13$...
    > 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
     
    John Harrison, Aug 13, 2004
    #12
  13. 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
     
    Karl Heinz Buchegger, Aug 13, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cronus
    Replies:
    1
    Views:
    676
    Paul Mensonides
    Jul 15, 2004
  2. Robin Cull
    Replies:
    5
    Views:
    407
    Andrew Dalke
    Jul 31, 2003
  3. Daniel Joyce

    Python Audio (Alpy, Fastaudio, Etc Etc)

    Daniel Joyce, Sep 16, 2003, in forum: Python
    Replies:
    1
    Views:
    925
    Markus Wankus
    Sep 16, 2003
  4. Kevin Walzer

    Re: PIL (etc etc etc) on OS X

    Kevin Walzer, Aug 1, 2008, in forum: Python
    Replies:
    4
    Views:
    410
    Fredrik Lundh
    Aug 13, 2008
  5. Wes Gamble
    Replies:
    1
    Views:
    161
    Gerardo Santana Gómez Garrido
    Apr 5, 2006
Loading...

Share This Page