Re: C++ bashing (was Re: Vendor bashing? Sort of.)

[dewar@cs.nyu.edu (Robert Dewar)]

Jonothan, if you reread my original post, I never said that C-Front was
not a compiler, I said that it was a preprocessor. These two classes are
certainly *not* mutually exclusive. Actually I don't even think that
compiler and interpretor are mutually exclusive.

Of these three terms, I find preprocessor to be the most precise. To me
it means precisely that you have a processor that takes one source language
and generates another which is then subsequently fed into an existing
compiler for the generated language. How much error checking the PP does
seems quite irrelevant to me (there can be compilers that do no checking
and PP's that do lots of checking). The two important charactersitics of
PP's to watch out for are end-to-end environment issues like debugging,
and inefficiencies that come from trying to map into an intermediate
language that cannot be changed (because it is defined, and the downstream
compiler cannot be modified), and might not in fact be appropriate. These
are not necessary problems, since C is set up to accomodate a preprocessor
of its own in any case, the end-to-end problems are often solved, and for
the initial version of C++ there are no serious inefficiencies that come
from the PP approach.

For either the current version of C++ (notably in the exception area), or
Ada (nested subprograms, subunits, and in particular checked arithmetic),
preprocessing into C is sure to cause significant inefficiencies since
these concepts just do not map efficiently into C. Of course one can
partially, but definitely not fully, mitigate these effects by providing
library routines.

So in short there is nothing inherently bad about the idea of preprocessing.
However, it is important to understand that, unlike C front, GNAT in no
sense generates intermediate C code. The reason that is important is that
if it did, it would have no chance of being really efficient. Since it in
fact does NOT generate C code, and since the backend of GCC can be and is 
being modified to accomodate Ada efficiently, there are no arbitrary
barriers to efficiency in GNAT (it's just a matter of time and effort 
to get rid of known sources of inefficiency).

Note that in a certain sense you could call all GCC compilers preprocessors
since they generate assembly language (a choice that is not necessarily the
most efficient in compile time, but carries no runtime penalty, and greatly
eases portability of the GCC system). However, the two possible penalties
for preprocessors are largely absent. Certainly ASM has on arbitrary
restrictions on what you can do. And in most systems, end to end issues
are well handled (although there are exceptions, GCC depends on an assembler
that can accept debugging information, and this is problematic in some
environments -- which is why, for example, there is still no GDB for OS/2).