Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!RODS.IUS.CS.CMU.EDU!jxw
From: jxw@RODS.IUS.CS.CMU.EDU (John Willis)
Newsgroups: comp.lang.c++
Subject: Re: service for gnu software (was: Re: C++ 2.0 pricing and licensing policy)
Summary: RE: Service for GNU software
Message-ID: <5670@pt.cs.cmu.edu>
Date: 27 Jul 89 02:44:25 GMT
References: <1481@ns.network.com> <8723@thorin.cs.unc.edu> <6590188@hplsla.HP.COM> <393@odi.ODI.COM>
Organization: Carnegie-Mellon University, CS/RI
Lines: 48

After reading several diatribes in this newsgroup against the Free
Software Foundation and G++ in particular, I feel compelled to share
an alternate viewpoint and experience.

For the last 9 months I have been working on a parallelizing compiler
written in C++.  After starting with AT&T tools, I ended up using GNU
tools because in all cases they were more reliable, faster, and had
better turn-around on problems than any commercial software I've used
in fifteen years of programming.

GNU's Flex (Lex upgrade) and Bison (YACC upgrade) are used to support
multiple language frontends and parallel parsers including a language
which has most of Ada's complexity (VHDL).  Most compilations of YACC
have tables too small to have any hope of handling the job.  Even with
early versions of Flex and Bison, there were never any problems which
slowed down debugging of my compiler.  Flex provides tunable parameters
which result in a scanner faster than I am willing to hand-craft.  They
are grade-A tools.

I initially started working with AT&T's C++ translator.  It dumped core,
produced cryptic diagnostics, or bogus code so often that I was about to 
dump C++ when I ran across Michael Tiemann's G++ effort.  From day one
it was an uplifting experience.  Although I avoid using features like
virtual classes for performance reasons, I have never run into any bugs
with G++ that stalled progress or took substantial time to isolate.  Even
while in Europe, Michael provided updates to the software every 2 to 6
weeks.  Little bugs were removed and available QUICKLY.  The resulting
code generation is excellent.  And I have little or no problem rapidly
moving the project from one host to another (because of G++, the software
is portable to many more machines than I could ever afford to worry about
on my own with native tools).

This is a single person PhD project.  I don't have the time to play games
with tools that don't work, take a lot of hand-holding, or translate into
a game of prepetual telephone-tag with technical support.  I want to 
finish this degree and be able to use (and share) the resulting VHDL 
compiler and simulator.

Even at the old prices AT&T was asking for their translator, I was
puzzled why anyone would not use the GNU tools.  Now, with the proposed
quantum increase in price, I can't see a good technical reason for not
trying GNU and G++.  Are those steering you away from GNU and GNU tools
actually speaking out of experience?  If so, how do they get anything
done with the average commercial software?  Try GNU and G++ yourself!
If you like what you see, do yourself and your profession a favour by
supporting the GNU project.

-John