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 <joseph...@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 > >
