headers - best practice?

[makc]

suppose you have a .cpp file that needs things from headers A and B,
and it is known that header A already includes B. should I still put
include B in .cpp just in case I will move some code related to B only
some day? or should I keep those countless #includes to the minimum?
what are other pros/cons?

 

[Kai-Uwe Bux]

suppose you have a .cpp file that needs things from headers A and B,
and it is known that header A already includes B. should I still put
include B in .cpp just in case I will move some code related to B only
some day? or should I keep those countless #includes to the minimum?
what are other pros/cons?

Headers are for the compiler to read, they are not documentation. You should
write your code according to the library documentation (meant for human
readers). Thus, if the library is documented so that including A.h includes
B.h, then you can just go with A.h. Otherwise, you should include B.h
separately since the documentations makes no promise that the stuff from
B.h is available. Unless documented, the fact that A.h makes available the
declarations from B.h is just an implementation detail.


Best

Kai-Uwe Bux

 

[Virtual_X]

suppose you have a .cpp file that needs things from headers A and B,
and it is known that header A already includes B. should I still put
include B in .cpp just in case I will move some code related to B only
some day? or should I keep those countless #includes to the minimum?
what are other pros/cons?

can you clarify what you want but i think that you need to include
the header b once in the .cpp so you can put this code in b to
or any other file to be ensure that that header will included
once

#ifndef _B_
#define _B_

(put your header content here)

#end if

 

[Victor Bazarov]

can you clarify what you want but i think that you need to include
the header b once in the .cpp so you can put this code in b to
or any other file to be ensure that that header will included
once

#ifndef _B_
#define _B_

Identifiers that begin with an underscore and a capital letter are
reserved by the implementation.

(put your header content here)

#end if

V

 

[Colander]

Headers are for the compiler to read, they are not documentation.

I don't agree. I do think it's best to "Don't repeat yourself". This
makes it necessary that the headers are the documentation, look at
Doxygen for example, a couple of well aimed comments and all will
understand what the code will do.

If I write separate documents the chance is very great there will be
discrepancies between the code and the documentation. In my opinion
this is even worse then no documentation.

 

[James Kanze]

suppose you have a .cpp file that needs things from headers A and B,
and it is known that header A already includes B. should I still put
include B in .cpp just in case I will move some code related to B only
some day? or should I keep those countless #includes to the minimum?
what are other pros/cons?

Anything you use directly, include the header file for it.
Anything which is only used indirectly, don't.

 

[James Kanze]

Headers are for the compiler to read, they are not documentation.

[/QUOTE]

I don't agree. I do think it's best to "Don't repeat yourself". This
makes it necessary that the headers are the documentation, look at
Doxygen for example, a couple of well aimed comments and all will
understand what the code will do.

The whole point of Doxygen is that headers aren't documentation.
You need to generate a different format for it to be useful.
(Significantly, the important point is often what isn't included
in the Doxygen generated files.)

IMHO, however, Doxygen does do things backwards. Generally
speaking, you want to write the documentation (external
specification), and generate the header from it. The problem is
that the header also usually needs additional information (e.g.
private data members) which aren't part of the interface
specification.

If I write separate documents the chance is very great there
will be discrepancies between the code and the documentation.

In which case, the code will fail review.

 

[Jim Langston]

suppose you have a .cpp file that needs things from headers A and B,
and it is known that header A already includes B. should I still put
include B in .cpp just in case I will move some code related to B only
some day? or should I keep those countless #includes to the minimum?
what are other pros/cons?

Personally, I use header guards, and would include both A.h and B.h in my
..cpp file if I am creating a type B. It just makes it easier for
maintanance when sometime in the future I see
class B
and wonder where class B is definred. I see
#incluce "B.h"
at the top of my source, no problem, I open the file and go on my way.
Without "B.h" being defined I would have to spend extra time figuring out
what header actually included class B.