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?

[Virtual_X]

On Jul 12, 3:04 pm, makc <[e-mail]:

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]

Virtual_X wrote:

On Jul 12, 3:04 pm, makc <[e-mail]:

>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_

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

>
(put your header content here)

#end if

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Jul 13, 12:04 am, makc <[e-mail]:

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jim Langston]

"makc" <ma************@gmail.comwrote in message
news:11*********************@g4g2000hsf.googlegrou ps.com...

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.