Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!news.funet.fi!hydra!kreeta!wirzeniu
From: wirzeniu@cs.Helsinki.FI (Lars Wirzenius)
Newsgroups: comp.lang.c
Subject: Re: A way to significantly speed up compiles?
Summary: I don't think so
Keywords: cpp
Message-ID: <10044@hydra.Helsinki.FI>
Date: 17 Dec 90 16:40:26 GMT
References: <1037@gistdev.gist.com>
Sender: news@cs.Helsinki.FI
Organization: University of Helsinki, Department of Computer Science
Lines: 36

>your constants too deeply.  The questions is, why not have cpp combine
>those numbers at pre-processor time?  Wouldn't it make a lot more
>sense to have cpp add 0+10+5+7 together once when ENTRY3 is #defined
>in cpp rather than making the compiler add those numbers together 100
>times in the 100 places that ENTRY3 is used? 

I can see two problems with this.  First of all, the preprocessor still
needs to be able to handle the stringizing operator, #.  This means that
you need to keep both the original text and the computed result around,
so the space savings are negative. 

A more serious problem is that the replacement text isn't necessarily a
complete expression. For example, the following would break:

	#define FOO	1+2
	FOO * 3

An evaluating preprocessor would expand this to

	3 * 3

whereas the correct result would be

	1+2 * 3

So the preprocessor can't use the evaluated replacement text unless it
can be *sure* the replacement doesn't change the meaning.  But computing
the safeness would probably take much more time (in a typical case) than
an unevaluating preprocessor. 

Furthermore, I don't think I've seen more than one case where #defines
where nested heavily (and that one case was during the discussion about
boolean typedefs a few months back, ISTRUE or something became a couple
of hundred kilobytes, or something...).  

Lars Wirzenius    wirzeniu@cs.helsinki.fi    wirzenius@cc.helsinki.fi