Xref: utzoo comp.lang.c:23306 comp.lang.c++:5230
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ginosko!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: A solution to the multiple inclusion problem
Message-ID: <2185@dataio.Data-IO.COM>
Date: 25 Oct 89 18:55:48 GMT
References: <14240@well.UUCP> <CIMSHOP!DAVIDM.89Oct24095658@uunet.UU.NET>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Distribution: comp
Organization: Data I/O Corporation; Redmond, WA
Lines: 23

In article <CIMSHOP!DAVIDM.89Oct24095658@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>In article <14240@well.UUCP> nagle@well.UUCP (John Nagle) writes:
<   (Many newer compilers do "#" processing in the same pass as main
<   compilation, so referring to a "preprocessor" in this context is not
<   necessarily correct.)
<I suppose that this is a performance enhancement and that now "#" processing
<is being considered so much a part of the language that compiler writers feel
<justified in doing this.  However, doesn't this limit flexibility?

Integrating the preprocessor into the parser is a big performance win
because you save a file write and read of the source. Loading and starting
one program is also faster than loading and starting two. The MS-DOS
compiler market is such that an integrated preprocessor is pretty much
required.

An integrated preprocessor has an advantage usually because it knows about
types and typedefs, so sizeof expressions can be used in #if expressions
(though ANSI C disallows it).

What you lose is the ability to run the preprocessor on non-C source files.
Note that integrating the preprocessor and the parser does not prevent
you from viewing the preprocessed output, there is usually a switch to
generate this.