Xref: utzoo gnu.g++.help:363 comp.lang.c++:11231 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!tut.cis.ohio-state.edu!sun2.brc.uconn.edu!beshers From: beshers@sun2.brc.uconn.edu (George Beshers) Newsgroups: gnu.g++.help,comp.lang.c++ Subject: Re: GNU g++ not ready for anything at all. Message-ID: <9101211440.AA04099@sun2.brc.uconn.edu> Date: 21 Jan 91 14:40:44 GMT Sender: daemon@tut.cis.ohio-state.edu Followup-To: gnu.g++.help Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu Lines: 121 # 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: # 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 # 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