maxwebb@ogicse.ogi.edu (Max G. Webb) (01/15/91)
This may not be an appropriate message; oh well... Just as a data point for everybody out there deciding whether to use g++: Last semester I wrote a neural net simulator in g++; I already had some experience in c++ (AT&Ts version), and in other OOPL's, and have been a programmer since '78. My impression was that the bugginess of the implementation has *DOUBLED* my implementation time. Recent releases (37.1) only seem to add to my work, by failing to compile code that used to work. So if you value your time (which it will waste), or your hair (which you will tear out), or your cool (which you will lose), go somewhere else. g++ will bring you mucho pain. Max
rjc@cs.ucla.edu (Robert Collins) (01/15/91)
In article <16008@ogicse.ogi.edu> maxwebb@ogicse.ogi.edu (Max G. Webb) writes: >This may not be an appropriate message; oh well... My experience with g++ has been very different. >Just as a data point for everybody out there deciding whether >to use g++: Last semester I wrote a neural net simulator in g++; >I already had some experience in c++ (AT&Ts version), and in >other OOPL's, and have been a programmer since '78. I have used g++ for a couple of years now, and have spewed out over 100,000 lines of g++ code. >My impression was that the bugginess of the implementation has >*DOUBLED* my implementation time. Recent releases (37.1) only >seem to add to my work, by failing to compile code that used to work. While I have encountered numerous bugs in various versions of g++, my coding time was rarely affected very much. In general, Michael's support has been incredible. In critical cases, he has sent me a patch within a day (more than once in about 15 minutes---at 2am!). Also, Michael was very responsive to my critical need for named return values. Max, did you report the bugs that you encountered? If not, I have no sympathy for you, and I hope everyone ignores your whining. If you did, what kind of response did you get? How did it compare to the response to cfront bug reports? Why didn't you switch to cfront? >So if you value your time (which it will waste), or your hair (which >you will tear out), or your cool (which you will lose), >go somewhere else. g++ will bring you mucho pain. I am a very satisfied g++ customer. It has not wasted my time, I have a full head of hair (a little gray, but that is due to the women in my life--past and present, not g++ :-). It has not caused me to lose my cool, and has been surprising painless. >Max rob collins -- ------------------------------------------------------------------------------- rjc@cs.ucla.edu CM++ on the CM2: The only way to fly. -------------------------------------------------------------------------------
grunwald@foobar.colorado.edu (Dirk Grunwald) (01/15/91)
> While I have encountered numerous bugs in various versions of > g++, my coding time was rarely affected very much. In general, > Michael's support has been incredible. In critical cases, he > has sent me a patch within a day (more than once in about 15 -- While this was true in the past, I must admit that I'm not certain it's true now. Granted, Cygnus & Michael have been putting considerable time into GCC-2, but g++ has really suffered for that effort. It's been several months since the last release, and numerous known bugs persist. Recent bug reports don't get much action other than ``fixed in v2''. Others (me included) have done some debugging and made fixes on a variety of machines, but without knowing what bugs have and haven't been fixed by ``G++ central'', you don't know what work you're duplicating (& time you're wasting). There's not much incentive to make extensive fixes. If I could afford it, I too would use SaberC++ (which *is* available, according to an ad I got). The cost is less than a contract for a working g++ from Cygnus and significantly less than the cost of hacking it myself (because my research time would go down the toilet).
vaughan@mcc.com (Paul Vaughan) (01/15/91)
From: rjc@cs.ucla.edu (Robert Collins) In article <16008@ogicse.ogi.edu> maxwebb@ogicse.ogi.edu (Max G. Webb) writes: >This may not be an appropriate message; oh well... My experience with g++ has been very different. >Just as a data point for everybody out there deciding whether >to use g++: Last semester I wrote a neural net simulator in g++; >I already had some experience in c++ (AT&Ts version), and in >other OOPL's, and have been a programmer since '78. I have used g++ for a couple of years now, and have spewed out over 100,000 lines of g++ code. >My impression was that the bugginess of the implementation has >*DOUBLED* my implementation time. Recent releases (37.1) only >seem to add to my work, by failing to compile code that used to work. While I have encountered numerous bugs in various versions of g++, my coding time was rarely affected very much. In general, Michael's support has been incredible. In critical cases, he has sent me a patch within a day (more than once in about 15 minutes---at 2am!). Also, Michael was very responsive to my critical need for named return values. . . . I am a very satisfied g++ customer. It has not wasted my time, I have a full head of hair (a little gray, but that is due to the women in my life--past and present, not g++ :-). It has not caused me to lose my cool, and has been surprising painless. I can believe both stories. I've also used g++ for about 2 years and work with a program with about 100,000 lines. G++ definitely wasted a lot of our time, mostly through bugs in multiple inheritance. On the other hand Tiemann definitely did provide rather awesome support. My impression is that both properties have changed significantly. There are a lot fewer bugs (but there are still bugs) and support is less forthcoming unless you pay for it. Also, g++ changes pretty rapidly, there should be a 2.0 version (don't ask me when, but I know it's in the making) that will radically change the quality issue. If you're choosing a c++ compiler, I'd say the biggest consideration is the debugger. Get one that has a debugger you can use TODAY. Worry about other issues when the time comes. I don't have experience with any other c++ debugger, but I'd rate gdb as marginal to poor. The situation we're in at the moment makes it almost totally unusable. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan ----------------------------------------------------------------------------------
pawel@cs.UAlberta.CA (Pawel Gburzynski) (01/16/91)
From article <16008@ogicse.ogi.edu>, by maxwebb@ogicse.ogi.edu (Max G. Webb): > This may not be an appropriate message; oh well... > > Just as a data point for everybody out there deciding whether > to use g++: Last semester I wrote a neural net simulator in g++; > I already had some experience in c++ (AT&Ts version), and in > other OOPL's, and have been a programmer since '78. > > My impression was that the bugginess of the implementation has > *DOUBLED* my implementation time. Recent releases (37.1) only > seem to add to my work, by failing to compile code that used to work. > > So if you value your time (which it will waste), or your hair (which > you will tear out), or your cool (which you will lose), > go somewhere else. g++ will bring you mucho pain. > > Max It is not my intention to argue, but I would like to mention an opposite case. I am about to finish a sizeable package for modelling low-level communication protocols in g++ and I haven't had a single problem with the compiler. Of course, I have managed to hit a few bugs, but they were no problems at all. Some time ago I switched from 1.37.1 to 1.37.2 (beta) and I didn't experience any mishap whatsoever. I am using quite a bit of the "object-oriented" stuff, including long inheritance chains, virtual methods, and multiple inheritance. The availability of the source code actually *REDUCED* my implementation time as I was able to move the compiler quickly to other machines and create my own cozy g++ environment. Pawel Gburzynski University of Alberta Department of Computing Science Edmonton, Alberta, CANADA T6G 2H1
don@zardoz.coral.com (Don Dewar) (01/17/91)
) Resent-From: uunet!ai.mit.edu!gnulists ) Return-Path: <gnulists@ai.mit.edu> ) Resent-Date: 14 Jan 91 23:59:53 GMT ) Original-To: gnu-g++-announce@uunet.uu.net ) Path: uunet!ogicse!maxwebb ) From: uunet!cse.ogi.edu!maxwebb (Max G. Webb) ) Sender: uunet!ai.mit.edu!gnulists ) Newsgroups: comp.lang.c++,gnu.g++.announce ) Subject: GNU g++ not ready for anything at all. ) Summary: not suitable for any particular purpose. ) Keywords: Just say no. ) Date: 14 Jan 91 23:59:53 GMT ) References: <1991Jan10.202317.161@ee.ualberta.ca> ) Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR ) Posted: Mon Jan 14 15:59:53 1991 ) To: bug-g++@prep.ai.mit.edu ) ) This may not be an appropriate message; oh well... ) ) Just as a data point for everybody out there deciding whether ) to use g++: Last semester I wrote a neural net simulator in g++; ) I already had some experience in c++ (AT&Ts version), and in ) other OOPL's, and have been a programmer since '78. ) ) My impression was that the bugginess of the implementation has ) *DOUBLED* my implementation time. Recent releases (37.1) only ) seem to add to my work, by failing to compile code that used to work. ) ) So if you value your time (which it will waste), or your hair (which ) you will tear out), or your cool (which you will lose), ) go somewhere else. g++ will bring you mucho pain. ) ) Max ) I have to refute this blasphemy. I don't know what you were using g++ on, but I have used g++ on SPARC and AViiON workstations, as well as using CFront on the AViiON and Glockenspiel on 386/ix's. When I was doing my work on AViiON's, my group wrote a rather extenstive program using CFront 2.0. Because of some of the merits of g++ (namely gdb support for g++), we decided to use g++ instead. The port took about a day, and we found minor descrepancies over the next week. From there on in we kept our code g++ and CFront compatible. When I moved to my new position, I took some C++ class that I had written for my own use on the AViiON's with me to my new job. Here we have SPARCstations. I got g++ from the distribution on uunet and built it along with any other GNU stuff I needed. My code compiled, linked and executed cleanly with one minor exception, that took me an hour to figure out and fix. Frankly, I don't know what more you could ask. Right now, we have a large application that we have written with g++ and have run into no major problems with g++. What more can I say? +---------+ | Coral | |@@@@@*@**| |@@*@@**@@| Don Dewar |*@@**@@@@| Coral Network Corporation, Marlborough, MA |@***@@@@@| Internet: don@coral.com |@@**@@@@@| Phone: (508) 460-6010 |*********| Fax: (508) 481-6258 |Networks | +---------+
beshers@sun2.brc.uconn.edu (George Beshers) (01/21/91)
# From gnulists@ai.mit.edu@RELAY.CS.NET@life.ai.mit.edu Sun Jan 20 00:08:53 1991 # Received: from brcvax.brc.uconn.edu by sun2.brc.uconn.edu (4.0/SMI-4.0) # id AA03563; Sun, 20 Jan 91 00:08:50 EST # Received: by brcvax.brc.uconn.edu (5.51/4.7) # id AA09473; Sun, 20 Jan 91 00:01:14 EST # Received: from relay.cs.net by RELAY.CS.NET id aa16420; 19 Jan 91 12:43 EST # Received: from life.ai.mit.edu by RELAY.CS.NET id aa01533; 19 Jan 91 12:48 EST # Received: by life.ai.mit.edu (4.1/AI-4.10) id AA25098; Thu, 17 Jan 91 20:09:56 EST # Return-Path: <gnulists@ai.mit.edu> # Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA25080; Thu, 17 Jan 91 20:09:06 EST # Received: by rice-chex (4.1/AI-4.10) id AA29395; Thu, 17 Jan 91 20:08:49 EST # Resent-Date: 15 Jan 91 19:54:54 GMT # Resent-From: gnulists@ai.mit.edu # Resent-Message-Id: <9101180108.AA29395@rice-chex> # Received: from mcsun.EU.net by life.ai.mit.edu (4.1/AI-4.10) id AA24647; Thu, 17 Jan 91 19:46:52 EST # Received: by mcsun.EU.net with SMTP; Fri, 18 Jan 91 01:46:46 +0100 # Received: from isaak # by unido.informatik.uni-dortmund.de with UUCP (UNIDO-2.0.3.d) via EUnet # for [192.16.202.1] # id AA03445; Fri, 18 Jan 91 00:48:10 GMT # Received: from escher.isa.de by isaak.isa.de (4.0/SMI-4.0/ISA-1.2) # id AA17808; Fri, 18 Jan 91 00:32:23 +0100 # Received: by escher.isa.de (4.0/SMI-4.0) # id AA10084; Fri, 18 Jan 91 00:32:34 +0100 # Original-To: unido!gnu-g++-announce@relay.eu.net # Path: escher!nadia!smurf!ira.uka.de!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!wuarchive!rice!uw-beaver!ubc-cs!alberta!pawel # From: Pawel Gburzynski <pawel@cs.ualberta.ca> # Sender: gnulists@ai.mit.edu # Newsgroups: comp.lang.c++,gnu.g++.announce # Subject: Re: GNU g++ not ready for anything at all. # Message-Id: <1991Jan15.195454.8527@cs.UAlberta.CA> # Date: 15 Jan 91 19:54:54 GMT # References: <16008@ogicse.ogi.edu> # Organization: University of Alberta, Edmonton, Alberta, Canada # To: help-g++@prep.ai.mit.edu # Resent-To: help-g++@prep.ai.mit.edu # Received: from relay.cs.net by brcvax.brc.uconn.edu; 19 Jan 91 23:57:27-EST (Sat) # Status: R # # >From article <16008@ogicse.ogi.edu>, by maxwebb@ogicse.ogi.edu (Max G. Webb): # > This may not be an appropriate message; oh well... # > # > Just as a data point for everybody out there deciding whether # > to use g++: Last semester I wrote a neural net simulator in g++; # > I already had some experience in c++ (AT&Ts version), and in # > other OOPL's, and have been a programmer since '78. # > # > My impression was that the bugginess of the implementation has # > *DOUBLED* my implementation time. Recent releases (37.1) only # > seem to add to my work, by failing to compile code that used to work. # > # > So if you value your time (which it will waste), or your hair (which # > you will tear out), or your cool (which you will lose), # > go somewhere else. g++ will bring you mucho pain. # > # > Max # # It is not my intention to argue, but I would like to mention an opposite # case. I am about to finish a sizeable package for modelling low-level # communication protocols in g++ and I haven't had a single problem with # the compiler. Of course, I have managed to hit a few bugs, but they were # no problems at all. Some time ago I switched from 1.37.1 to 1.37.2 (beta) # and I didn't experience any mishap whatsoever. # # I am using quite a bit of the "object-oriented" stuff, including long # inheritance chains, virtual methods, and multiple inheritance. # # The availability of the source code actually *REDUCED* my implementation time # as I was able to move the compiler quickly to other machines and create my # own cozy g++ environment. # # # Pawel Gburzynski # University of Alberta # Department of Computing Science # Edmonton, Alberta, CANADA T6G 2H1 # # I will add my two cents in; I have found that upgrading C software is reasonably straight forward. That inheritance and virtual functions work fine. However, constructors and destructors can get called at `funny' times with the result that some algorithms are hard to follow---I now have a rule never to try anything algorithm critical based on constructor and destructor code. The real problem is that even with gdb+ and catches to avoid inlining functions for debugging purposes these errors can be difficult to discover for experienced C++ programmers and routinely blow my junior and senior software majors out of the water. Also, operator overloading occasionally catches me out by doing something I didn't expect. I have not used multiple inheritance that much, but there is no way to understand some of the intricacies without some understanding of the implementation technique. This is also true of the constructors and destructors---at least in my opinion. Finally, while C++ is better that C, Pascal, Fortran, ... by a long shot at creating libraries, and with the addition of templates will be a serious rival to Ada it is also possible to get unexpected side effects which make code re-use somewhat treacherous (not that Ada doesn't have similar problems.) The result is that I will not use library code to which I do not have source: it is absolutely essential for debugging if constructors and destructors don't work the way you expect for something. Basically, I think that upward compatibility from C has been the bane and boon of C++. A language with most of the constructs of C++ and a formal definition (see R. Milner, R. Harper, and M. Tofte ``The definition of standard ML'', MIT Press, 1990 for a good example of what a language definition should be) would be welcome. NOT that I think B. Stroustrup has done badly. Rather, I see C++ as an inheritantly experimental language; as such it is a tremendous success in that it has given a lot of insight into useful programming techniques which could not have been obtained in any other way. This does not mean that I would feel happy in a plane where a substantial amount of onboard software was written in C++; I wouldn't. George Beshers