Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!haven!udel!burdvax!dvnspc1!gary
From: gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Summary: Should I upgrade Zortech C++
Message-ID: <855@dvnspc1.Dev.Unisys.COM>
Date: 7 Dec 89 15:30:24 GMT
References: <6427@tekgvs.LABS.TEK.COM> <252@intek01.UUCP>
Organization: Unisys Corporation, Devon, PA
Lines: 29

In Mark McWiggins writes:
> *ahem* 'twas I ... No, a true compiler should be *faster in compiling* and
> probably easier to debug, but the quality of generated code when using a
> C++ translator then depends upon the underlying C compiler.  A translator
> then gives you choice of the processor for which you generate code, as well:
> 8088 or 80386 or 34010, or whatever C compiler you have.
> 
> No doubt native-code compilers will come to predominate in coming years, but
> for the moment Cfront certainly has a niche to fill.
> 
> And obviously I'm totally prejudiced on this point ...


Note that AT&T's first support of C++ was in fact a pre-processor
which generated "standard" C source.  I thought that was a great idea
at the time, since we could write C++ programs and then feed the AT&T
output to the target C compiler of our choice (not AT&T's, one which
we considered more optimized for our particular target machine).  

AT&T's approach was flexible and valid for our particular
requirements.   So you may be prejudiced, but on good grounds, I
believe.
-- 
========================================================================
Gary L. Barrett

My employer may or may not agree with my opinions.
And I may or may not agree with my employer's opinions.
========================================================================