Re: Faster compilation speed

[Noel Yap <yap_noel at yahoo dot com>]

--- Neil Booth <neil@daikokuya.co.uk> wrote:
> Noel Yap wrote:-
> 
> > The study also indicates that having #include's
> within
> > header files is the largest contributor to the
> problem
> > (since nested #include's would increase the number
> of
> > file accesses combinatorially).
> 
> See below for why this isn't true for most compilers
> now.
> 
> > As another indication that the conclusion is true,
> > Lakos added guards around the #include lines
> > themselves and found compile times to dramatically
> > decrease.  For example:
> > #if header_h
> > #   include <header.h>
> > #endif
> 
> This isn't the case with GCC.  I hope you're aware
> of that.
> The first time GCC reads <header.h> it remembers if
> it had
> header guards.  If it's ever asked to #include it
> again,
> it checks if the guard is defined, and doesn't do
> anything.
> The file's contents are also not cached if it has
> header
> guards, on the assumption that the contents are
> unlikely to
> be of interest in the future.
> 
> In other words, this kind of #include protection is
> ugly and
> pointless (and possibly error-prone, though that
> would tend
> to be immediately obvious).  Most compilers now
> implement
> this optimization, but 5 or 6 years ago this wasn't
> the case.
> I think GCC was one of the first.

I stand corrected.  (I'm assuming gcc doesn't do this
in cases where the header guard might have side
effects or if there's a matching #else for the
#ifndef).

Do you think precompiled headers would help build
speed across several compiles since it would be
another source to eliminate repeated file opens?

Thanks,
Noel

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com