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

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
parts.h
parts/
parts/A.H
parts/B.H
parts/...
other.h
other/....

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.

2¢,
__armando

On Sat, Jan 16, 2010 at 10:41 AM, Joseph Xu <josephzxu_AT_gmail.com> wrote:
> 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 - 18:36:28 UTC