"vsgdp" <cl********@yahoo.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.com...
>
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:
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 <stringin my header file. The
include guards inside of <stringprevent 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.