inclusion guards

[vsgdp]

I was looking at some library code today and noticed something like
this:

// sublibrary.h

// define some constants, enums, symbols

#include "componentA.h"
#include "componentB.h"
#include "componentC.h"
#include "componentD.h"

Then each componentX.h file #includes sublibrary.h in order to get the
defined constants, enums and such. At first I thought this would be a
problem because it seemed circular, however, it works because each
component header file #includes "sublibrary.h" outside the inclusion
guards:

// example: componentA.h

#include "sublibrary.h"

#ifndef COMPONENTA_H
#define COMPONENTA_H

// class of ComponentA

#endif

If #include "sublibrary.h" was inside the inclusion guards, it would
not work since ComponentA would get defined twice.

So my question is: Is this style common or generally recommended?

 

[Howard]

I was looking at some library code today and noticed something like
this:

// sublibrary.h

// define some constants, enums, symbols

#include "componentA.h"
#include "componentB.h"
#include "componentC.h"
#include "componentD.h"

Then each componentX.h file #includes sublibrary.h in order to get the
defined constants, enums and such. At first I thought this would be a
problem because it seemed circular, however, it works because each
component header file #includes "sublibrary.h" outside the inclusion
guards:

// example: componentA.h

#include "sublibrary.h"

#ifndef COMPONENTA_H
#define COMPONENTA_H

// class of ComponentA

#endif

If #include "sublibrary.h" was inside the inclusion guards, it would
not work since ComponentA would get defined twice.

I think that's backwards. Having the #include "sublibrary.h" outside the
include guards causes it to *always* include sublibrary.h, even if the
current file is itself being included from sublibrary.h itself! And that's
a problem. perhaps there are include guards in sublibrary.h as well, which
are preventing its contents from being included in a circular fashion?

So my question is: Is this style common or generally recommended?

I can't recall ever having seen such a setup. It makes no sense to me. A
more common scenario would be if sublibrary.h forward-declared whatever it
needed to know about from those other header files, instead of including
them. (Or vise-versa.)

But as far as I know, circular inclusion of headers isn't normal, regardless
of the placement of header include guards.

-Howard

 

[Gianni Mariani]

vsgdp wrote:
....

... each
component header file #includes "sublibrary.h" outside the inclusion
guards:

// example: componentA.h

#include "sublibrary.h"

#ifndef COMPONENTA_H
#define COMPONENTA_H

// class of ComponentA

#endif
....

So my question is: Is this style common or generally recommended?

Both common and recommended.

 

[Gianni Mariani]

I think that's backwards. Having the #include "sublibrary.h" outside the
include guards causes it to *always* include sublibrary.h,

Assuming that sublibrary.h uses it's own inclusion guard, why would this
be a problem ?

even if the

current file is itself being included from sublibrary.h itself! And that's
a problem. perhaps there are include guards in sublibrary.h as well, which
are preventing its contents from being included in a circular fashion?


I can't recall ever having seen such a setup.

It should not matter but having just checked, I put my includes inside
my guards. So what I wrote in the other post about it being common is
wrong, however it should make no difference whatsoever (other than the
compiler taking a little more time in processing the include more often
that necessary).

 

[Howard]

Assuming that sublibrary.h uses it's own inclusion guard, why would this
be a problem ?

That assumption is exactly what I speculated on in the text below:

even if the

I was trying to say that circular inclusions are not (in general) correct in
the first place, and that putting the #includes before the include guards
was not what prevented the problem. Rather, what made it work was likely
that there was an include guard in sublibrary.h as well.

-Howard

 

[vsgdp]

That assumption is exactly what I speculated on in the text below:

Yes, sorry for not making that clear, sublibrary.h did use its own
inclusion guards. Anyway, I don't like the style so I will personally
avoid it, but I was just wondering if this is common to see.

 

[Jim Langston]

Yes, sorry for not making that clear, sublibrary.h did use its own
inclusion guards. Anyway, I don't like the style so I will personally
avoid it, but I was just wondering if this is common to see.

It is common for a header file that needs other header files to be compiled
include them itself. For example, if I have a header file for a class that
uses std::string, then I would include <string> in my header file. The
include guards inside of <string> prevent problems with this, and it makes
it a lot easier to include header files inside a source file without having
to worry about what order they're included in.

If you have proper include guards inside of your sublibrary.h then
componentA.h won't really bring it in with #include "sublibrary.h" (this is
what's bad about snipping too much from previous posts, people will have to
go back to the original message to find out what I'm talking about).

The real question becomes, does it make sense for componentA.h to need to
include sublibrary.h if sublibrary.h also needs to include componentA.h. If
it was required then it wouldn't compile because of circular dependancies,
but since it is compiling, it seems you're including one or the other
needlessly. Maybe you just want the user of componentA.h to also have all
the defines of componentA, B, C, D and sublibrary.h when they include it,
because that's whats going to happen. Any time the user includes any it
will include all, probably needlessly.

Most likely, you just need sublibrary.h to include componentA.h B, C and D.
Then the user when they include componentA.h to only get what they need. If
they need something in B, C, D or sublibrary.h then have them include it
also.