header guard

[asdf]

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.

 

[Jim Langston]

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

 

[Rolf Magnus]

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.

 

[asdf]

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

 

[mlimber]

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

 

[dasjotre]

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'

 

[Rolf Magnus]

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.

 

[asdf]

Thank you very much.

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.

 

[Old Wolf]

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.

 

[Dave Steffen]

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?

 

[Old Wolf]

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).

 

[Craig Scott]

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.

 

[Jim Langston]

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.

 

[Rolf Magnus]

I don't care what the freaking standard says.

Then you're in the wrong place here.

 

[Dave Steffen]

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?

 

[Marcus Kwok]

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.