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 lo
On Sat, Jan 16, 2010 at 10:41:40AM -0500, Joseph Xu wrote:
> So my first question is, has anybody actually ran into problems due
> to violating this rule?
Sometimes there is two headers that depend on some third. First header
includes this third and the second header don't (you may forgot to do
it
> You might not be having problems but he's saying that all that code passing
> through the lexical analyser will be slowing the compile down. If you put
> the #ifdef in the top file doing the includes then include files will be
> opened only the once and not many times.
What I did on the Amiga wa
On 16/01/10 15:41, Joseph Xu wrote:
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 vi
> 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
Of course you did not run into problems. You just wasted your precious
processor time on including and parsing header files which you could
have easily prevented
by following that rule.
You might however run into problems when breaking this rule and no
#ifdef-guards are present.
I'm not sure abou
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 file
