Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!red-dwarf.Eng.Sun.COM!pallas From: pallas@red-dwarf.Eng.Sun.COM (Joseph Pallas) Newsgroups: comp.object Subject: Re: C++ and garbage collection (long, but interesting :->) Message-ID: <142839@sun.Eng.Sun.COM> Date: 21 Sep 90 00:48:10 GMT References: <1990Sep16.090226.11051@tukki.jyu.fi> <1990Sep18.131307.984@tukki.jyu.fi> Sender: news@sun.Eng.Sun.COM Lines: 56 In pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> The definition of "in use" being that its address as if returned by the pcg> storage allocator appears in one or more pointers in storage. pcg> It merely excludes all erroneous programs, i.e. all those that pcg> violate the interface contract with the storage manager. This is a novel interpretation, I should say. The C++ language most definitely does not include such a constraint in the language definition. sakkinen> For instance, suppose we have a case of multiple inheritance sakkinen> where class D is some other base class than the first, of class E. sakkinen> If we now create an object by 'new E' and cast the resulting pointer sakkinen> to the type 'D*', it will no more point to the same address that sakkinen> the allocator returned (at least in some implementations of C++). pcg> Well, in that case you cannot use that pointer as operand to operator pcg> delete either, so if you are doing manual storage reclamation your pcg> object has become unreclaimable -- unless you keep around a pointer to pcg> the 'E*', in which case no problem arises under any reclamation policy. This is a substantial constraint you are suggesting: automatic storage reclamation that works correctly only if the program can be transformed, by just the addition of delete operations, into one that correctly reclaims all garbage with manual storage reclamation. We seem to agree that the set of such programs is smaller than the set of valid/legal programs. pcg> It would be 'in-use' as long as the resulting pointer did not pcg> have a different *format* (I very carefully wrote that) from that pcg> returned by the storage allocator and returned by the storage pcg> deallocator; in your example the format is not changed, just the pcg> value of the pointer is. No, you did not very carefully write that. What you very carefully wrote (above) was that the address of the object (i.e., the VALUE, not just the format) appears in a pointer in storage. You seem to be assuming your conservative collector honors all interior pointers. But that is not what you are writing. It is no wonder that this is causing confusion. pcg> Note that the conservative reclaimer will do one better than even pcg> a manual one using free(3) or operator delete would, because if pcg> these were used either one would have to reclaim all of the pcg> structure, ... or could not reclaim the structure even if the pcg> reference ... were lost .... Now you're not making sense. Either you honor interior pointers or you don't. If you do, your collector cannot reclaim anything in this example. If you don't, your above claims are invalidated. Which is it? joe