Path: utzoo!attcan!utgpu!watmath!att!dptg!rutgers!cs.utexas.edu!uunet!ncrlnk!ncr-sd!hp-sdd!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Questions about "Free Software Foundation"
Message-ID: <6590261@hplsla.HP.COM>
Date: 21 Sep 89 00:08:11 GMT
References: <980@mrsvr.UUCP>
Organization: HP Lake Stevens, WA
Lines: 37

>>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++...

...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.

>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.

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
a standard C compiler generates assembly that your assembler turns into
machine code -- if your C compiler ever generated assembly that your
assembler couldn't handle -- then that would represent a bug in either
your C compiler, or your assembler.  True compilers are distinguished
by always generating correct output, or nothing at all [barring compiler
bugs :-]