header guard

Discussion in 'C++' started by asdf, Nov 21, 2006.

  1. asdf

    asdf Guest

    I am confused by the header guard, for example,

    #ifndef SALESITEM_H
    #define SALESITEM_H
    .....
    #endif

    what is the "SALEITEM_H" ? It is a variable name, or something else? I
    could not find "SALESITEM_H" in all the files, so, I don't know where
    "SALEITEM_H" come from.

    Thanks.
    asdf, Nov 21, 2006
    #1
    1. Advertising

  2. asdf

    Jim Langston Guest

    "asdf" <> wrote in message
    news:...
    >I am confused by the header guard, for example,
    >
    > #ifndef SALESITEM_H
    > #define SALESITEM_H
    > ....
    > #endif
    >
    > what is the "SALEITEM_H" ? It is a variable name, or something else? I
    > could not find "SALESITEM_H" in all the files, so, I don't know where
    > "SALEITEM_H" come from.
    >
    > Thanks.


    It is anything you want it to be and should be unqiue, but generally it's
    the name of the header file. For SALESITEMS_H I would presume the header
    file name was
    SalesItems.h

    It's pretty much an unwritten rule that variables in all caps ending in _H
    are used for header guards.

    So if you made a header file called

    AsdfTools.h
    you would make the header guard

    #ifndef ASDFTOOLS_H
    #define ASDFTOOLS_H
    //...
    #endif
    Jim Langston, Nov 21, 2006
    #2
    1. Advertising

  3. asdf

    Rolf Magnus Guest

    asdf wrote:

    > I am confused by the header guard, for example,
    >
    > #ifndef SALESITEM_H
    > #define SALESITEM_H
    > ....
    > #endif
    >
    > what is the "SALEITEM_H" ? It is a variable name, or something else?


    It's the name of a macro.

    > I could not find "SALESITEM_H" in all the files, so, I don't know where
    > "SALEITEM_H" come from.


    It comes from just the lines that you quoted.
    Rolf Magnus, Nov 21, 2006
    #3
  4. asdf

    asdf Guest

    Thanks.
    Could you please explain more about the aim (or the advantage) of the
    header guard in your example ?

    Jim Langston wrote:
    > So if you made a header file called
    >
    > AsdfTools.h
    > you would make the header guard
    >
    > #ifndef ASDFTOOLS_H
    > #define ASDFTOOLS_H
    > //...
    > #endif
    asdf, Nov 21, 2006
    #4
  5. asdf

    mlimber Guest

    asdf wrote:
    > I am confused by the header guard, for example,
    >
    > #ifndef SALESITEM_H
    > #define SALESITEM_H
    > ....
    > #endif
    >
    > what is the "SALEITEM_H" ? It is a variable name, or something else? I
    > could not find "SALESITEM_H" in all the files, so, I don't know where
    > "SALEITEM_H" come from.


    It is a preprocessor symbol. It should only exist on the lines you show
    above. If it isn't defined on the first line, the second line defines
    it into existence. If it's already defined when you reach the first
    line (e.g., if you include the same header twice in one .cpp file),
    then the preprocessor will strip all the stuff between the #if and the
    #endif, including the #define on the second line.

    Cheers! --M
    mlimber, Nov 21, 2006
    #5
  6. asdf

    dasjotre Guest

    asdf wrote:
    > I am confused by the header guard, for example,
    >
    > #ifndef SALESITEM_H
    > #define SALESITEM_H
    > ....
    > #endif
    >
    > what is the "SALEITEM_H" ? It is a variable name, or something else? I
    > could not find "SALESITEM_H" in all the files, so, I don't know where
    > "SALEITEM_H" come from.
    >
    > Thanks.


    #if SOMETHING
    This part of the file will be processed by the compiler
    only if the SOMETHING symbol is defined
    #endif

    compiler might find more than one #include
    statement for a single header in multiple
    compile units. to prevent multiple declarations
    you need to prevent it processing it more than once.

    #ifndef SALESITEM_H // if this symbol is not defined
    #'define SALESITEM_H // define it

    declarations

    #endif

    so the first time it encounters this header
    the symbol will not be defined and the file
    will be processed. On following visits
    the symbol will be defined and the content
    of the file will not be processed again.

    Google for 'preprocessor'
    dasjotre, Nov 21, 2006
    #6
  7. asdf

    Rolf Magnus Guest

    asdf wrote:

    > Thanks.
    > Could you please explain more about the aim (or the advantage) of the
    > header guard in your example ?


    If a translation unit includes the header multiple times, let's say there is
    a header x.h which includes AsdfTools.h and a header y.h that does, too,
    and then you include both in your .c file, you end up having AsdfTools.h
    included twice in it. This usually leads to problems (multiple
    definitions), so the include guard idiom is used to ensure that the part
    between the #ifndef and the #endif is excluded if the header is read a
    second or third time.

    > Jim Langston wrote:
    >> So if you made a header file called
    >>
    >> AsdfTools.h
    >> you would make the header guard
    >>
    >> #ifndef ASDFTOOLS_H
    >> #define ASDFTOOLS_H
    >> //...
    >> #endif
    Rolf Magnus, Nov 21, 2006
    #7
  8. asdf

    asdf Guest

    Thank you very much.

    Rolf Magnus wrote:
    > asdf wrote:
    >
    > > Thanks.
    > > Could you please explain more about the aim (or the advantage) of the
    > > header guard in your example ?

    >
    > If a translation unit includes the header multiple times, let's say there is
    > a header x.h which includes AsdfTools.h and a header y.h that does, too,
    > and then you include both in your .c file, you end up having AsdfTools.h
    > included twice in it. This usually leads to problems (multiple
    > definitions), so the include guard idiom is used to ensure that the part
    > between the #ifndef and the #endif is excluded if the header is read a
    > second or third time.
    >
    > > Jim Langston wrote:
    > >> So if you made a header file called
    > >>
    > >> AsdfTools.h
    > >> you would make the header guard
    > >>
    > >> #ifndef ASDFTOOLS_H
    > >> #define ASDFTOOLS_H
    > >> //...
    > >> #endif
    asdf, Nov 21, 2006
    #8
  9. asdf

    Old Wolf Guest

    Jim Langston wrote:
    >
    > It's pretty much an unwritten rule that variables in all caps ending in _H
    > are used for header guards.
    >
    > So if you made a header file called
    >
    > AsdfTools.h
    > you would make the header guard
    >
    > #ifndef ASDFTOOLS_H
    > #define ASDFTOOLS_H


    It shouldn't be. What if your filename starts with E ? All identifiers
    beginning with an uppercase E followed by a digit or an uppercase
    letter, are reserved for implementation use.
    Old Wolf, Nov 21, 2006
    #9
  10. asdf

    Dave Steffen Guest

    "Old Wolf" <> writes:

    > Jim Langston wrote:
    > >
    > > It's pretty much an unwritten rule that variables in all caps ending in _H
    > > are used for header guards.
    > >
    > > So if you made a header file called
    > >
    > > AsdfTools.h
    > > you would make the header guard
    > >
    > > #ifndef ASDFTOOLS_H
    > > #define ASDFTOOLS_H

    >
    > It shouldn't be. What if your filename starts with E ? All identifiers
    > beginning with an uppercase E followed by a digit or an uppercase
    > letter, are reserved for implementation use.
    >


    Uhh... really? The standard says anything containing a double
    underscore, or that starts with an underscore and is in the global
    scope, is reserved (17.4.3.1.2). Chapter and verse for the
    uppercase E thing?

    ----------------------------------------------------------------------
    Dave Steffen, Ph.D. Disobey this command!
    Software Engineer IV - Douglas Hofstadter
    Numerica Corporation
    dg@steffen a@t numerica d@ot us (remove @'s to email me)
    Dave Steffen, Nov 22, 2006
    #10
  11. asdf

    Old Wolf Guest

    Dave Steffen wrote:
    > "Old Wolf" <> writes:
    > > Jim Langston wrote:
    > > >
    > > > It's pretty much an unwritten rule that variables in all caps ending in _H
    > > > are used for header guards.
    > > >
    > > > So if you made a header file called
    > > >
    > > > AsdfTools.h
    > > > you would make the header guard
    > > >
    > > > #ifndef ASDFTOOLS_H
    > > > #define ASDFTOOLS_H

    > >
    > > It shouldn't be. What if your filename starts with E ? All identifiers
    > > beginning with an uppercase E followed by a digit or an uppercase
    > > letter, are reserved for implementation use.

    >
    > Uhh... really?


    Section 19.3 (errno.h) referes to the C standard. I only have the C99
    standard, but I believe the section is similar or the same as it was in
    C90. The C99 section is 7.5#4:

    Additional macro definitions, beginning with E and a digit or E and
    an uppercase letter,173) may also be specified by the implementation.

    And 7.1.3 says:

    Each macro name in any of the following subclauses (including the
    future library directions) is reserved for use as specified if any of
    its associated headers is included; unless explicitly stated
    otherwise

    So, I should have said that Exxx is reserved only if errno.h or cerrno
    is included. Seeing as it might be, I think that Exxx is a poor choice
    of name for an include guard. (I write mine as H_FILENAME).
    Old Wolf, Nov 22, 2006
    #11
  12. asdf

    Craig Scott Guest

    > > Thanks.It is anything you want it to be and should be unqiue, but generally it's
    > the name of the header file. For SALESITEMS_H I would presume the header
    > file name was SalesItems.h


    For very large projects, you sometimes have files with the same name
    but in different directories. This means you need a slightly different
    convention. We have settled on a system where we put the namespace(s)
    followed by the class name in the header file. For example, for
    Foo::Bar::MyClass the symbol would be FOO_BAR_MYCLASS_H. We tried using
    the directory path from some top level root, but the symbols were
    getting too long for some files. The namespaces typically have shorter
    names than our directories and are not nested as deeply. For the few
    header files containing something other than a class, we usually use
    the file name instead of the class name but still retain the namespace
    parts. This seems to work well for us and is fairly predictable.

    --
    Computational Fluid Dynamics, CSIRO (CMIS)
    Melbourne, Australia
    Craig Scott, Nov 22, 2006
    #12
  13. asdf

    Jim Langston Guest

    "Old Wolf" <> wrote in message
    news:...
    > Dave Steffen wrote:
    >> "Old Wolf" <> writes:
    >> > Jim Langston wrote:
    >> > >
    >> > > It's pretty much an unwritten rule that variables in all caps ending
    >> > > in _H
    >> > > are used for header guards.
    >> > >
    >> > > So if you made a header file called
    >> > >
    >> > > AsdfTools.h
    >> > > you would make the header guard
    >> > >
    >> > > #ifndef ASDFTOOLS_H
    >> > > #define ASDFTOOLS_H
    >> >
    >> > It shouldn't be. What if your filename starts with E ? All identifiers
    >> > beginning with an uppercase E followed by a digit or an uppercase
    >> > letter, are reserved for implementation use.

    >>
    >> Uhh... really?

    >
    > Section 19.3 (errno.h) referes to the C standard. I only have the C99
    > standard, but I believe the section is similar or the same as it was in
    > C90. The C99 section is 7.5#4:
    >
    > Additional macro definitions, beginning with E and a digit or E and
    > an uppercase letter,173) may also be specified by the implementation.
    >
    > And 7.1.3 says:
    >
    > Each macro name in any of the following subclauses (including the
    > future library directions) is reserved for use as specified if any of
    > its associated headers is included; unless explicitly stated
    > otherwise
    >
    > So, I should have said that Exxx is reserved only if errno.h or cerrno
    > is included. Seeing as it might be, I think that Exxx is a poor choice
    > of name for an include guard. (I write mine as H_FILENAME).


    Even if that is the case, errno.h is not going to be defining macros ending
    in _H (except for it's own header guard maybe) so it should be perfectly
    fine. I just opened up my systems errno.h to see what kind of defines they
    were doing and they're like:

    #define EPERM 1
    #define ENOENT 2
    #define ESRCH 3
    #define EINTR 4
    #define EIO 5
    etc... No conflicts with *_H

    Stating that we can't define any all upcase names starting with E is just
    ludicrious, I don't care what the freaking standard says.
    Jim Langston, Nov 22, 2006
    #13
  14. asdf

    Rolf Magnus Guest

    Jim Langston wrote:

    > I don't care what the freaking standard says.


    Then you're in the wrong place here.
    Rolf Magnus, Nov 22, 2006
    #14
  15. asdf

    Dave Steffen Guest

    "Old Wolf" <> writes:

    > Dave Steffen wrote:
    > > "Old Wolf" <> writes:
    > > > Jim Langston wrote:
    > > > >
    > > > > It's pretty much an unwritten rule that variables in all caps ending in _H
    > > > > are used for header guards.
    > > > >
    > > > > So if you made a header file called
    > > > >
    > > > > AsdfTools.h
    > > > > you would make the header guard
    > > > >
    > > > > #ifndef ASDFTOOLS_H
    > > > > #define ASDFTOOLS_H
    > > >
    > > > It shouldn't be. What if your filename starts with E ? All identifiers
    > > > beginning with an uppercase E followed by a digit or an uppercase
    > > > letter, are reserved for implementation use.

    > >
    > > Uhh... really?

    >
    > Section 19.3 (errno.h) referes to the C standard. I only have the C99
    > standard, but I believe the section is similar or the same as it was in
    > C90. The C99 section is 7.5#4:
    >
    > Additional macro definitions, beginning with E and a digit or E and
    > an uppercase letter,173) may also be specified by the implementation.


    Yoiks, Zounds, and other comments. OK; E followed by a digit or
    capital letter is out.

    >
    > And 7.1.3 says:
    >
    > Each macro name in any of the following subclauses (including the
    > future library directions) is reserved for use as specified if any of
    > its associated headers is included; unless explicitly stated
    > otherwise
    >
    > So, I should have said that Exxx is reserved only if errno.h or cerrno
    > is included. Seeing as it might be, I think that Exxx is a poor choice
    > of name for an include guard. (I write mine as H_FILENAME).


    I'm not sure I follow this point. Is the notion that errno.h can
    define something like "Errno" as part of its include guards?

    ----------------------------------------------------------------------
    Dave Steffen, Ph.D. Disobey this command!
    Software Engineer IV - Douglas Hofstadter
    Numerica Corporation
    dg@steffen a@t numerica d@ot us (remove @'s to email me)
    Dave Steffen, Nov 27, 2006
    #15
  16. asdf

    Marcus Kwok Guest

    Dave Steffen <> wrote:
    > "Old Wolf" <> writes:
    >> And 7.1.3 says:
    >>
    >> Each macro name in any of the following subclauses (including the
    >> future library directions) is reserved for use as specified if any of
    >> its associated headers is included; unless explicitly stated
    >> otherwise
    >>
    >> So, I should have said that Exxx is reserved only if errno.h or cerrno
    >> is included. Seeing as it might be, I think that Exxx is a poor choice
    >> of name for an include guard. (I write mine as H_FILENAME).

    >
    > I'm not sure I follow this point. Is the notion that errno.h can
    > define something like "Errno" as part of its include guards?


    I think the notion is that errno.h can define something like "Errno" as
    *any part* of its implementation.

    --
    Marcus Kwok
    Replace 'invalid' with 'net' to reply
    Marcus Kwok, Nov 27, 2006
    #16
    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. Kuan Zhou

    Guard

    Kuan Zhou, Jan 24, 2005, in forum: VHDL
    Replies:
    3
    Views:
    2,345
    Allan Herriman
    Jan 24, 2005
  2. Marcus Liddle
    Replies:
    2
    Views:
    467
  3. Samuel
    Replies:
    0
    Views:
    273
    Samuel
    Jan 14, 2007
  4. Replies:
    11
    Views:
    542
    Jack Klein
    Oct 21, 2005
  5. Barry

    Exception Safe Guard

    Barry, Sep 4, 2007, in forum: C++
    Replies:
    5
    Views:
    433
    Barry
    Sep 5, 2007
Loading...

Share This Page