Path: utzoo!attcan!uunet!mcsun!ukc!cam-cl!scc
From: scc@cl.cam.ac.uk (Stephen Crawley)
Newsgroups: comp.sw.components
Subject: Re:  Re: Vagueness [was Re: Garbage Collection & ADTs]
Message-ID: <908@scaup.cl.cam.ac.uk>
Date: 23 Sep 89 01:50:46 GMT
References: <900@scaup.cl.cam.ac.uk> <6530@hubcap.clemson.edu> <11885@polya.Stanford.EDU> <902@scaup.cl.cam.ac.uk> <282@alfred.Teknowledge.COM>
Sender: news@cl.cam.ac.uk
Organization: U of Cambridge Comp Lab, UK
Lines: 47

Michael Wolf writes:

> I don't see what the problem is with passing around private types
> with pointers to reference-counted ADT's.  It adds a small amount of
> overhead to pointer references, and a couple bytes per object for
> reference counts.  If you've got a language which enforces the
> "private" part, you're pretty damn sure that your reference count
> is correct, and it's then easy to tell when it is or isn't okay
> to deallocate an object.

Ok so far ... sort of

> The only thing you need is a destructor
> routine called on each "private" pointer when it goes out of scope
> or get's deallocated.

And there's the problem with this scheme.

As I tried to explain before, scope based deallocation works if and
only if:

  1) the scope DOES exit. [The global scope and the scope of main() 
     NEVER exit for the sake of this argument.]
  2) the scope exits BEFORE we start running out of space
  3) and we can afford the extra storage overhead of remembering
     that we allocated object X in this scope Y.  [You either need
     to build a chain of objects allocated at each scope level or
     a new heap for each scope level ...]
     
In general, one of the above criteria does not hold.  This means that
we must rely on some other mechanism to tell the ADT to apply the
destructor to a given instance at the appropriate time.  

I claim that this means that the application programmer needs to deal
with this in significant percentage of the cases.  This is possible,
but it is very difficult to get correct when (for instance) the private
pseudo-pointer type is itself passed around the place in complicated
ways or when it is stored in dynamic data structures.

Bill Wolfe maintains that the problem can be solved with a higher level 
library ADTs that implement generic list, tree, graphs etc.  I claim he 
is incorrect and have presented an example (see <902@scaup.cl.cam.ac.uk>) 
which I believe demonstrates this. 

Lets try not to rehash old arguments ...

-- Steve