Large scale C++ software design,

[E. Robert Tisdale]

You don't put redundant guards in your .cpp files.
You put them in header files (when you include other header files).

This was a maintenance nightmare.
If you changed the name of the internal guard macro in a header file,
you had to change the name of the external guard macro to match
in every header or source file that included it.

 

[Shezan Baig]

This was a maintenance nightmare.
If you changed the name of the internal guard macro in a header file,
you had to change the name of the external guard macro to match
in every header or source file that included it.

Not really. Why would you change it? The name of the include guard is
derived from the name of the header file. There should be no need to
change it. Unless of course you change the name of your header file,
in which case you would *have* *to* grep for all references to it
anyway.

Hope this helps,
-shez-

 

[Shezan Baig]

This was a maintenance nightmare.
If you changed the name of the internal guard macro in a header file,
you had to change the name of the external guard macro to match
in every header or source file that included it.

Not really. Why would you change it? The name of the include guard is
derived from the name of the header file. There should be no need to
change it. Unless of course you change the name of your header file,
in which case you would *have* *to* grep for all references to it
anyway.

Hope this helps,
-shez-

 

[E. Robert Tisdale]

Not really. Why would you change it?
The name of the include guard is derived from the name of the header file.

Where is it written that, "The name of the include guard
is derived from the name of the header file."

 

[Shezan Baig]

Where is it written that, "The name of the include guard
is derived from the name of the header file."

Sorry, I didn't make my point totally clear with that quote. I didn't
intend for it to mean "it *must* be derived from the header file", but
it is definitely highly recommended. See Lakos p82, paragraph 2.

Hope this helps,
-shez-

 

[davidrubin]

FYI, the technique is implemented something like this: for
everycomponent file "foo.h" the include guard is called INCLUDED_FOO.
Now, coupled with package prefixes, each component file is actually
called "my_foo.h" and "your_foo.h", and the include guards are
INCLUDED_MY_FOO and INCLUDED_YOUR_FOO. This way, all filenames, and all
include guard names are unique across the project (and hopefully the
company). /david

 

[Jonathan Turkanis]

Not really. Why would you change it? The name of the include guard
is derived from the name of the header file. There should be no need
to change it. Unless of course you change the name of your header
file, in which case you would *have* *to* grep for all references to
it anyway.

One way the include guard names and the header names can get out of sync is when
a header is renamed but the internal include guards are not updated.

Jonathan

 

[Ioannis Vranos]

Pragmas are by definition implementation-defined.

There are two sides to the issue: following language rules and good
large-scale system design. They are orthogonal. If some compiler
features that aren't in the language proper allow you to achieve
a better result in the system design, who is to tell you not to use
it because "it can not be considered portable"? Who cares that it
is not portable if it does what it intends to do?

IOW, don't get hung up on portability.

Yes, however still the standard could have adopted #pragma once as an
alternative to inclusion guards.

 

[Ioannis Vranos]

One way the include guard names and the header names can get out of sync is when
a header is renamed but the internal include guards are not updated.

I do not know about the embedded world, however in the PC world most
(all?) IDEs provide the ability of "(find and) replace all" so you can
change a text found anywhere in the project with another text.