All right, this is the snag. My class, foo, has private members of the type std::string, but most other parts of the program (which need foo), are very happy to go without these type of strings. But since interface and implementation usually share header file, all files that #include foo.h also need to #include <string>.

I've bothered myself about this common(?) issue for a while, and even played dirty tricks by hiding all private declarations with preprocessor #ifdefs. So I ask you, honourable gurus, to lend any guidance or comments on this!

After preprocessing foo.h, string.h becomes part of foo.h for it's #included in it. So when the implementation file (say foo.cpp) #includes foo.h it "inherits" all the headers #included in foo.h

Or do I understand your question wrong?

Yea, that's how I usually do it. And I'm a little shy to depart from established practice.

Well, I guess this is the prevalent way - that each header file sorts out its own dependencies. I just think it is a bit contaminating, since only the implementation needs direct access to the private declarations of its own header file.

Don't get me wrong. This is not a big deal. It's just an interesting aspect of the way C/C++ is designed. Perhaps this is more of a linguistic question.

Yip, that is a fact of life. The only solution (not partticularly wonderful) is the pimpl idiom. Google is your friend to find out more.

Thanks! After reading a bit about pimpl I understand why many use C and not C++.

Nope. Using C won't help you. In fact the problem comes from C++'s C roots.

I think it is all just a run time optimization tweak. Thus when you say...
myFunc()
{
MyHairyClass mhc;
}

The compiler can emit an immediate value for the sizeof(MyHairyClass) which is more effcient than loading in a linked in value. That's my guess.