Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!bruce!trlluna!rhea.trl.oz.au!aduncan
From: aduncan@rhea.trl.oz.au (Allan Duncan)
Newsgroups: comp.sys.amiga
Subject: Re: AllocRemember()
Message-ID: <1230@trlluna.trl.oz>
Date: 28 Mar 90 03:08:01 GMT
References: <90086.093011UH2@psuvm.psu.edu>
Sender: root@trlluna.trl.oz
Lines: 32

From article <90086.093011UH2@psuvm.psu.edu>, by UH2@psuvm.psu.edu (Lee Sailer):
> Though I had never used it myself, I'd always wondered why more people
> don't use this memory allocator.  It works something like this:
> 
.
.
.
> So, I think one reason few people use AllocRemember() is that there is
> some misleading documentation about it, so people get frustrated by
> it.  Other reasons are that ARP offers a similar service, plus it
> isn't that hard to create your own, similar capability once you see
> the need for it.
> 
>                 lee

I have also devised a method for generalizing this chaining to cover all
resources.  If you are doing the job properly and checking for (say) a
library, and it is unavailable and you need to abort the program, you
end up with more code for freeing what you had got up to that point than
it took to get there!
Solution - create a list (with backward linking) that has a pointer to
the resource, some parameter (say, size), and a pointer to a function
that will release it (eg free() for a malloc'd chunk).  When it comes
time to back out, just call a routine that runs back down the list,
checking for a non-null resource pointer (you might have already let it
go) and invoking the freeing function.  Takes a bit to set up the first
time, but is easy to re-use.

Allan Duncan	ACSnet	a.duncan@trl.oz
		ARPA	a.duncan%trl.oz.au@uunet.uu.net
		UUCP	{uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan
Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.