Xref: utzoo comp.lang.c++:4242 comp.lang.eiffel:341 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!apple!oliveb!Ozona!chase From: chase@Ozona.orc.olivetti.com (David Chase) Newsgroups: comp.lang.c++,comp.lang.eiffel Subject: Re: Eiffel vs. C++ -- Let's drop the garbage collection arguments Message-ID: <45901@oliveb.olivetti.com> Date: 2 Aug 89 18:55:38 GMT References: <6590148@hplsla.HP.COM> <14489@watdragon.waterloo.edu> <779@redsox.bsw.com> Sender: news@oliveb.olivetti.com Reply-To: chase@Ozona.UUCP (David Chase) Followup-To: comp.lang.c++ Organization: Olivetti Research Center, Menlo Park, CA Lines: 24 In article <779@redsox.bsw.com> campbell@redsox.UUCP (Larry Campbell) writes: >Modula-3, by contrast, allows you to decide on a type-by-type basis whether >objects of the type are to be GC'd or not. This seems to me to be the best >solution. To be fair, this is only somewhat the case. In code that is explicitly declared as UNSAFE you are allowed to choose on a type-by-type basis whether or not objects are GC'd or not. In practice, most code should *not* be unsafe (though some very important code will be unsafe), and writing unsafe code places a much greater burden on the programmer. It really isn't much different from writing C, except that many more errors become the fault of the programmer, and the run-time system is not really tuned to make life easy for the author of unsafe code. For example, if you store a pointer to garbage-collected memory in a record field that is declared to be an INTEGER, the memory could be reused. That's a programmer error. If you store a pointer to gc memory at an unapproved offset (i.e., odd byte alignment), the memory could be reused. That's a programmer error. If you write unsafe code, then it is presumed (as so many C programmers are quick to claim) that you know what you are doing. David