C++ includes

[Alf P. Steinbach]

* Jacob:

It is common recommendation that C++ header
files should be "self-sufficient", i.e. they
should directly include every concept it use
and not rely on getting this information
through other includes.

Is this the case also for source files?

A header file is a source file: with that interpretation the question is
meaningless.

If you mean module implementation files then the question assumes that a
module implementation is #include'd in some other file, and then your
question boils down to: should module implementation files be #include'd?

And the answer to that is no.

 

[Jacob]

It is common recommendation that C++ header
files should be "self-sufficient", i.e. they
should directly include every concept it use
and not rely on getting this information
through other includes.

Is this the case also for source files?

Thanks!

 

[benben]

A source file, of course, must contain all information necessary either by
#including corresponding headers or having it as part of the file.
Generally, if something in a source is not declared before use, you won't be
able to compile it.

Ben

 

[Jacob]

A source file, of course, must contain all information necessary either by
#including corresponding headers or having it as part of the file.
Generally, if something in a source is not declared before use, you won't be
able to compile it.

An "include file" is declaration and protected againts
multiple includes by a include guard, right?

Consider the following two rudimentary include files:

IncludeA.h:
-----------
#include <string>
class A;


IncludeB.h:
-----------
#include "IncludeA.h"
class B {
public:
A a;
string name;
};


I would claim it as an error for IncludeB.h *NOT* to include
<string> as its declaration (B) depend on the string concept.

You don't get a compiler error nor warning (perhaps a warning
would be appropriate) by nut including it, as <string> is
included indirectly through IncludeA.

This is a common knowlegde and most styleguides will suggest
you include <string> in this case to stay independent of internal
changes in IncludeA.


My question is if this should be the case also for difinition
files (.c++ files)? You may claim that by including the declaration
"IncludeA", you inherit the lot, and there is no need to include
<string> separately as you got it for free already.

Any suggestions?

Thanks!

 

[benben]

An "include file" is declaration and protected againts
multiple includes by a include guard, right?
Correct!


Consider the following two rudimentary include files:

IncludeA.h:
-----------
#include <string>
class A;


IncludeB.h:
-----------
#include "IncludeA.h"
class B {
public:
A a;
string name;
};


I would claim it as an error for IncludeB.h *NOT* to include
<string> as its declaration (B) depend on the string concept.
Correct!


You don't get a compiler error nor warning (perhaps a warning
would be appropriate) by nut including it, as <string> is
included indirectly through IncludeA.

No, you don't get a compiler error.

This is a common knowlegde and most styleguides will suggest
you include <string> in this case to stay independent of internal
changes in IncludeA.

That's correct!

My question is if this should be the case also for difinition
files (.c++ files)? You may claim that by including the declaration
"IncludeA", you inherit the lot, and there is no need to include
<string> separately as you got it for free already.

Same rule, the source file #includes "IncludeA.h" for class A, "IncludeB.h"

Any suggestions?

Thanks!

No worries!

Ben