Path: utzoo!attcan!telly!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rit!cci632!tvf
From: tvf@cci632.UUCP (Tom Frauenhofer)
Newsgroups: comp.lang.c++
Subject: Re: Questions about "Free Software Foundation"
Message-ID: <30765@cci632.UUCP>
Date: 22 Sep 89 13:31:59 GMT
References: <980@mrsvr.UUCP> <6590261@hplsla.HP.COM>
Reply-To: tvf@ccird7.UUCP (Tom Frauenhofer)
Organization: CCI, Communications Systems Division, Rochester, NY
Lines: 53

In article <6590261@hplsla.HP.COM. jima@hplsla.HP.COM (Jim Adcock) writes:
>In a previous article, I wrote
.>.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).
.In my experience, I have found 2.0 to be much more reliable than the 
.prior AT&T releases, and more reliable than g++.

Fine.  That is good.  How about more pro/con from the rest?

P.S.: A representative from AT&T has been taking me to task about my
statement about X.0 releases and that since I have no experience with
CFRONT 2.0, then I should be quiet about the matter.  If most others have
the same good things to say about CFRONT 2.0, then AT&T has improved their
software quality assurance, and other companies could take some notes from
them (when it comes to major releases of software, at least).

....Which is not why I don't recommend g++ for commercial work.  I don't
.recommend g++ for commercial work because then your company's copyright
.gets entangled with the Gnu copyleft restrictions.  I'm sure a sufficiently
.clever lawyer could get around this, but what would be the point?  You'd
.be better off (as a commercial user) to pay AT&T and be free to use 
.the generated code as you please.

Only using the libg++ library does the GNU copyleft problem arise.

.>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.
.CPP is a macro processor.  You can see this by making errors in
.your C code that passes silently through CPP, only to cause your C 
.compiler to barf.  Cfront never generates C code that causes your C
.compiler to barf -- except in the rare cases where there is either a 
.compiler bug in cfront, or a compiler bug in your C compiler.  Likewise

I will take back publicly (to the happiness of the AT&T person who has been
mailing me his comments) that CPP is a compiler if CFRONT is.

.True compilers are distinguished
.by always generating correct output, or nothing at all [barring compiler
.bugs :-]

Yes, but unfortunately, enough untrue products from various vendors have
come onto the market to make cynics of us all (please take note of this,
my friend at AT&T).

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