From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Why C++ is successful Date: 1998/08/07 Message-ID: #1/1 X-Deja-AN: 378955891 References: <6qfhri$gs7$1@nnrp1.dejanews.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 902521278 6863 bpr 206.184.139.132 Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-08-07T00:00:00+00:00 List-Id: On Fri, 7 Aug 1998 harald.mueller@siemenscom.com wrote: > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > Most certainly! GC introduces a huge risk for incorrect programs. Garbage > > collectors assume that the pointer structure of a program is correct. If > > it is corruptede, garbage collectors can cause horrible havoc. Indeed this > > havoc often only shows up after several mark-and-sweep type cycles of the > > GC, and it can be almost impossible to track them down > > > > (said from horrible experiences in implementing general GC!) > > Now that's interesting. I did never write a GC, but I wrote a heap management > system, which had bugs in it for the first few weeks, and you wouldn't > believe it: A correct GC would have been MUCH BETTER than my wrong heap > management. So? I have nothing against GC, in fact I like it in general and wish its use was more widespread, but a very large part of your problem is that the language you are working in (1) Doesn't distinguish between pointers to local variables and pointers to heap allocated memory. (2) Allows you to get a pointer to any local variable, rather than forcing you to be explicit about which local variables can be pointed to, or "aliased". (3) Makes it easy to do all kinds of other arbitrary weird things with pointers. In an otherwise very similar language, Ada, none of these are a problem. Sure, the user could always declare every local variable as aliased, and make every pointer "access all" to point to heap and local variables, and insist on using Unchecked_Access ("&" in C/C++) and Unchecked_Conversion (casting) to turn off all the checks, but the presence of "Unchecked_" anything tells you where the problem might be. Modula-3 has the requirement that any module which uses unsafe features of the language be labelled as UNSAFE, which is an idea I like too, though it also has GC so you proabbly wouldn't write allocators in M3. I tend to think of Ada as being semantically similar to C++ (especially wrt to the fact that Ada allows low level programming), except that while C++ allows you to be safe, the defaults are unsafe, and while Ada allows you to be unsafe, the defaults are safe. Since I'm sort of a slapdash programmer, I prefer help from the compiler to avoid the sort of mishaps Harald describes. Doubtless the C++ experts out there who are writing reliable code are a lot smarter than me and don't need this kind of help, or they get it by using tools like Lint and Purify; probably both. I don't have the same problems in Ada that I do in C or C++, even though I'm *far* more familiar with C than Ada (I use C every day). -- Brian