🚀 go-pugleaf

# 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