Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!peregrine!ccicpg!cci632!tvf
From: tvf@cci632.UUCP (Tom Frauenhofer)
Newsgroups: comp.lang.c++
Subject: Re: Questions about "Free Software Foundation"
Message-ID: <30712@cci632.UUCP>
Date: 19 Sep 89 14:26:11 GMT
References: <980@mrsvr.UUCP> <6590249@hplsla.HP.COM>
Reply-To: tvf@ccird7.UUCP (Tom Frauenhofer)
Organization: CCI, Communications Systems Division, Rochester, NY
Lines: 61

In article <6590249@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes (in
reply to another's questions)
>
>>1. Are there any users on the net who have
>>   used their compiler/debugger?

>I have used g++ and gcc, and others here swear by their debugger.  G++ generates
>pretty good code, but slightly more efficient code is generated by using AT&Ts
>cfront compiler as the front end and gcc as the back end.

>>4. If you've used their stuff, would you recommend it?
>
>Not for commercial work.  For acedemic work, or playing around, maybe.

CFRONT 1.2 was DOA at many sites due to its many bugs.  I don't know about
CFRONT 2.0, but I have a general distrust for any release of software that
is numbered X.0 (from my experience, first major releases of a software
package are fairly buggy.  I'm not claiming CFRONT 2.0 is buggy, just
stating my experience).

I've used g++ and found it (and most other GNU packages) to be solid tools.
And the bug-fix turn-around time is quite short.  And you get source.  And
the price is reasonable.

>Note, the AT&T compiler tends to be a little ahead of g++ in terms of having
>the latest language features implemented.

No argument here, but the lag time between AT&T adding new language features
and their incorporation into g++ is not all that great.

>>Furthermore, it is a real c++ compiler as opposed
>>to CC which translates c++ to c and then compiles the c.
>>Wendy

>CC is a real compiler that is targeted to a "C-language-machine."  It uses
>"C" as the generated assembly language, if you will.

CC invokes the CFRONT pre-processor that converts your c++ code into
something that can be digested by the C compiler.  I can accept this
definition of compiler providing you now consider CPP (the C pre-processor)
is a compiler as well.  It uses "C" as the generated assembly language, too.
On the other hand, g++ generates {assembly?  Object? I forget} for the target
system.  I find it easier to debug using g++/gdb than using
CC/whatever-debugger-you-have-on-hand.

>I believe some companies
>have already successfully retargeted the AT&T compiler to generate 
>proprietary assembly language for their particular CPUs.  The major advantage
>of doing this is to allow vendor-specific debugging tools to be used.  
>Slight performance gains may also be possible.

This could be a win, depending on the implementation.  Unfortunately, you
have to be using one of these hardware platforms.  Which vendors are doing
this?  I am curious.

I'm not flaming or cussing or the like, just playing devil's advocate.  I
just feel that the GNU tools got a shorter shrift than they deserve.

Thomas V. Frauenhofer	...!rutgers!rochester!cci632!ccird7!tvf
*or* ...!rochester!kodak!swamps!frau!tvf
"The Earth? I'm going to blow it up.  It obstructs my view of Venus" - Martin