Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!cam-cl!scc From: scc@cl.cam.ac.uk (Stephen Crawley) Newsgroups: comp.sw.components Subject: Re: List ADT example Message-ID: <928@scaup.cl.cam.ac.uk> Date: 29 Sep 89 12:16:33 GMT References: <917@scaup.cl.cam.ac.uk> <6624@hubcap.clemson.edu> Sender: news@cl.cam.ac.uk Organization: U of Cambridge Comp Lab, UK Lines: 35 I wrote: >> if you insist that I use a different generic list ADT >> (say POINTER_LIST), please explain how it does storage management >> without pushing the tricky part (in particular the decision about when >> reference counts should be incremented or decremented) back to application >> code. Bill Wolfe replied: > This is the price you pay for wanting to store references instead > of objects. An object can only be in one place at a time. I read this as a tacit admission that you can't come up with such a list ADT! If so, all your arguments about applications not using pointers, and the hard problems storage management being safely and efficiently handled by generic ADTs fall apart like a pack of cards. Sure generic ADT's may work for simple cases, but for data structures with multiple references the generic ADT can be no more efficient than a modern GC. If the application programmer wants more efficiency, he could try to do the storage management himself, using special knowledge about the application in hand. But this relies on the special knowledge being true knowledge (no mistakes, no mythology), and on the application programmer not writing incorrect code that leaks store, or leaves dangling pointers, or uses heap nodes after they have been freed, etc. The GC versus non-GC argument boils down to a tradeoff between correctness and reliability on the one hand versus potential for efficiency improvement on the other. The correctness and reliability of GC'ed storage management is ASSURED. The potential increased efficiency of non-GC'ed storage management is vanishingly small in many cases, and in all but simple cases depends on non-trivial development effort by applications programmers. -- Steve