Re: Faster compilation speed

[Noel Yap <yap_noel at yahoo dot com>]

--- Neil Booth <neil@daikokuya.co.uk> wrote:
> Noel Yap wrote:-
> 
> > I don't see this as too big a problem.  Just
> output a
> > file like:
> > #if COND
> > /* contents of header file
> > #endif
> > 
> > In fact, doing it this way has the advantage that
> > several builds, not necessarily agreeing on the
> value
> > of COND, can use the file.
> 
> Hmm, and what about header guards?  Infinite
> recursion?

Unless I'm missing something, header guards by
themselves shouldn't pose a problem.

You're right.  Cyclic dependencies would throw this
whole thing out of whack.  OTOH, I think such practice
needs to be avoided anyhow.

Another case related to recursive includes is where
each level of recursion would have side effects (eg
redefining a macro whose value is used in the next
recursion).  Again, I've heard this usage only once
and even the creator of such a header file said it was
a tremendous hack for programmers with no proper
education in programming (IIRC, they were physicists).

> > I think one needn't preprocess everything
> perfectly in
> > order to gain significant advantages.  Would you
> say
> > that what I suggest is better than what we have
> now?
> 
> Correctness is paramount; if it's not correct it's
> no
> good.

I apologize if my post was misunderstood.  What I
meant to say was, if it's able to preprocess, then
allow it, otherwise, don't.  IOW, those already
following common practices can take advantage of a new
feature, those that don't have what they have now.

I can certainly understand the ideals of keeping the
tool and all its features pure and working for all
possible uses.  OTOH, doing so may prevent practicle
avenues that possibly 99% of users can benefit from.

Noel


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