home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: gnu.g++.help
- Path: sparky!uunet!boulder!news!grunwald
- From: grunwald@tile.cs.colorado.edu (Dirk Grunwald)
- Subject: Re: generating source code
- In-Reply-To: hwrvo@kato.lahabra.chevron.com's message of 23 Jul 92 17:57:29 GMT
- Message-ID: <1992Jul24.045939.21074@colorado.edu>
- Followup-To: gnu.g++.help
- Lines: 22
- Sender: news@colorado.edu (The Daily Planet)
- Nntp-Posting-Host: tile.cs.colorado.edu
- Reply-To: grunwald@foobar.cs.colorado.edu
- Organization: University of Colorado at Boulder
- References: <1992Jul21.234225.1664@tc.fluke.COM> <9207230635.AA13746@rtl.cygnus.com>
- <5378@lhdsy1.lahabra.chevron.com>
- Date: Fri, 24 Jul 1992 04:59:39 GMT
- Lines: 22
-
-
- I would hasten to disagree with all of your points.
-
- + I find GCC produces equivilent or better code than the supplied compiler
- on the machines I use (Sequent i386, SPARC, DECstation,.
-
- + Most of the errors in g++ appear to stem from incorrect implementation
- in the g++ front-end, vague C++ language semantics (``moving target'').
- Since gcc uses the same back-end, the backend tends to be very robust
- and stable.
-
- + You can not debug cfront-produced C code. That's a major reason for
- using a real compiler (or having a way to pass this information through
- your C compiler).
-
- + Cfront can't do somethings G++ can do, because it must translate to C
- (i.e. it has restrictions on 'inline' functions).
-
- All this said and done, I still think it's useful to have a C backend
- to gcc/g++ -- in part, because I want to use g++ on a particular
- machine (KSR-1) for which I don't want to build a backend (it's a pain
- to debug, and secondary to my immediate goals).
-