Re: [dev] include files should never include include files?

From: Armando Di Cianno <>
Date: Sat, 16 Jan 2010 13:36:28 -0500

Odd - my gut reaction seeing the title made me suppose it was for
/usability/ reasons. The technical reasons, make sense though.

I worked for a company that generated a lot of header files in the
course of work (think lots of different #define's for lots of
different bit moving and whatnot for lots of different boards). We
came up with this structure, basically:


all.h would include everything overall, and parts.h would include all
of parts/*.h, in those rare times that you needed something like that;
also, it was easy to automate generation of these files.


On Sat, Jan 16, 2010 at 10:41 AM, Joseph Xu <> wrote:
> A little off topic maybe, hope I'll be forgiven ...
> I'm reading Rob Pike's C programming style guide
> (, 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 - 18:36:28 UTC

This archive was generated by hypermail 2.2.0 : Sat Jan 16 2010 - 19:12:02 UTC