Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!decwrl!megatest!djones From: djones@megatest.UUCP (Dave Jones) Newsgroups: comp.sw.components Subject: Problem requiring GC -- try again. Message-ID: <8310@goofy.megatest.UUCP> Date: 27 Sep 89 01:29:10 GMT References: <911@scaup.cl.cam.ac.uk> Organization: Megatest Corporation, San Jose, Ca Lines: 39 From article <911@scaup.cl.cam.ac.uk>, by scc@cl.cam.ac.uk (Stephen Crawley): > Golden Richard III writes: > > Here are some problems where programmer-controlled storage management > would be very difficult or impossible. > > Interactive editting of cyclic graph data structures. You have a > heterogeneous cyclic graph data structure and the editor must be able > to make arbitrary sequences of changes to the data structure. How > do you detect that a subgraph has become detached? > Funny you should ask, because I'm working on such a problem even as we speak, sans garbage-collector. The editor is not interactive -- it is essentially an optimizer which reduces graphs by calculating equivalency classes of subgraphs -- but I don't see that that matters much whether it is interactive or not. I handled the sitch by making an "arrow" a proper data-object, not just a vanilla pointer. One extra pointer's worth of memory per arrow, but cheap at twice the price! Before I had that brainstorm I had all sorts of problems, the very least of which was reclaiming memory. (A wise man once said, if you don't understand the problem well enough to know when an object is unreachable, you don't understand the problem well enough.) Here it is, simplified only a little, to be generic: typedef struct { Info node_info; /* Info that the node carries */ List arrows_out; /* List of all arrows pointing to this node */ List arrows_in; /* List of all arrows pointing out of this node */ }Node; typedef struct { Symbol label; /* Symbol which labels this arrow */ Node *from; /* Node at the base of this arrow */ Node *to; /* Node at the point of this arrow */ }Arrow;