Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!news.funet.fi!tukki.jyu.fi!sakkinen From: sakkinen@tukki.jyu.fi (Markku Sakkinen) Newsgroups: comp.object Subject: Re: C++ and garbage collection (Was: Re: What is Objective C?) Message-ID: <1990Sep18.131307.984@tukki.jyu.fi> Date: 18 Sep 90 13:13:07 GMT References: <1990Sep16.090226.11051@tukki.jyu.fi> Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen) Organization: University of Jyvaskyla, Finland Lines: 59 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > ... >The definition of "in use" being that its address as if returned by the >storage allocator appears in one or more pointers in storage. If you are >using any other definition of "in use" you are making your own rules, >and we are no longer speaking of storage allocation or reclamation as is >described in the current academic literature on the subject. Aha, we have been playing with different rules. I thought we were talking about the applicability of GC to _general_ C++ programmes. You in contrast are intending only code that obeys certain additional constraints. I have no objection to the statement that "GC is applicable to C++ programmes as far as they obey rules that make them susceptible to GC." The constraint that you suggest above seems extremely severe for C++. For instance, suppose we have a case of multiple inheritance where class D is some other base class than the first, of class E. If we now create an object by 'new E' and cast the resulting pointer to the type 'D*', it will no more point to the same address that the allocator returned (at least in some implementations of C++). This is legal, sound, and commonplace C++ usage, but according to your rule the object would no more be "in use". In fact, I am afraid that the above rule would not allow completely safe GC to be implemented even for Pascal, although its pointer handling is so much more restricted. (I can try to construct an example if requested.) > ... >Even free(3) will fail if you pass it an encrypted or XOR-ed or >otherwise encoded form of a pointer. (Since we are speaking about C++, we should refer to the 'delete' operator instead of the 'free' function, which is unknown to C++ standards unless it has surfaced in Release 2.1.) Certainly, but 'delete' does not require that you have preserved the pointer exactly in its original form, without interruption, all the time from 'new'. That's the difference! > ... >It is *much* safer for application programmers to leave reclamation in >the hands of a purpose built reclaimer, than to try to design their own >reclamation policy and algorithm, and even system programmers, that know >the problems, find manual storage reclamation difficult to get right. I agree, but my conclusion is: programmers should prefer cleaner OO languages that make things like this possible, and not C++. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)