From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ffce418d7a49585f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-05 03:33:54 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!cs.utexas.edu!uunet!psinntp!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: C++ bashing (was Re: Vendor bashing? Sort of.) Date: 4 Oct 1994 14:44:15 -0400 Organization: Courant Institute of Mathematical Sciences Message-ID: <36s7pv$pqk@gnat.cs.nyu.edu> References: <35nlhb$6u0@gnat.cs.nyu.edu> <85BA331C6A0@annwfn.com> <36rucbINN4gr@marble.summit.novell.com> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-10-04T14:44:15-04:00 List-Id: 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).