[dev] include files should never include include files?

A little off topic maybe, hope I'll be forgiven ...

I'm reading Rob Pike's C programming style guide
(http://www.quut.com/c/pikestyle.html), and the last rule says:

----------------------------------------------------------------------

Simple rule: include files should never include include files. If
instead they state (in comments or implicitly) what files they need to
have included first, the problem of deciding which files to include is
pushed to the user (programmer) but in a way that's easy to handle and
that, by construction, avoids multiple inclusions. Multiple inclusions
are a bane of systems programming. It's not rare to have files included
five or more times to compile a single C source file. The Unix
/usr/include/sys stuff is terrible this way.

      There's a little dance involving #ifdef's that can prevent a file
being read twice, but it's usually done wrong in practice - the #ifdef's
are in the file itself, not the file that includes it. The result is
often thousands of needless lines of code passing through the lexical
analyzer, which is (in good compilers) the most expensive phase.

      Just follow the simple rule.

----------------------------------------------------------------------

This is a little surprising to me as I'm used to putting includes in
include files all the time. I do use #ifdef header guards, and I've
never really had any problems violating this rule. So my first question
is, has anybody actually ran into problems due to violating this rule?
And secondly, does this rule apply to C++? For example, if I'm defining
a class that std::vector members, I ordinarily add a #include<vector> in
the header.

Thanks for the advice.

Joseph
Received on Sat Jan 16 2010 - 15:41:40 UTC