"Ben Chambers" <bdc### [at] yahoocom> wrote>
> The explicitness of a preprocessing stage has nothing to do with the
> language itself.  For instance, MSVC will automatically, preprocess,
compile
> and link objects all in one step.  gcc on the other hand, has separate
tools
> for preprocessing, compiling, assembling, and linking (though you have a
> common 'control' file to do it all at once).  In one of them, it is very
> explicit; in the other, it is implicit.  But they both work.

Exactly. I would add that, long ago, there was such a thing as Zortec C
compiler (that product was first named Datalight Optimum C, then Zortec
C/C++, then Symantec C/C++; highly regarded; written by Walter Bright) that
had separate parsing (parse tree generation), optimization, and code
generation stages; with intermediate files, of course :-) But does that
prove anything?

I do think that if a language *defines* distinct pre-processing stage, that
*unnecessary* limits it, to a great extent (more on this in another
message). In C, many things could have been rectified if 'const' were
defined properly (not as a mere storage class specifier, but in a way it was
done in C++), and 'inline' were timely introduced in standard (and not
merely provided as extensions by vistually every compiler vendor).

> That being said, I think it's important to maintain the distinction
between
> the preprocessing and the processing.  In fact, it might be useful to have
> an option for outputting a preprocessed file, in case someone needs to see
> exactly how their loops are unrolling or something like that.

I do not think this would be useful at all... How often do you look at the
output of C preprocessor? As to me, I have a definit answer: about a dozen
times -- when I was tweaking Decus CPP (freeware C preprocessor) to my needs
:-)

Post a reply to this message