Subject: Re: Allocating on the stack and *only* on the stack From: Erik Naggum <erik@naggum.net> Date: 12 Dec 2000 14:54:07 +0000 Newsgroups: comp.lang.lisp Message-ID: <3185621647787532@naggum.net> * Fernando Rodríguez <spam...@must.die> | What I really need is what Tim said in a previous post: an action to | be performed when a class instance gets out of scope. Oh, I see. I should have realized that when C++ and Java programmers talk about objects that are "freed", freeing _memory_ is nowhere near what they really talk about, they talk about running destructors, and I got a little hung up in terminology and your need to allocate on the stack and talk about the GC, which confused me. Sorry about that. One does these things with macros that utilize unwind-protect to run cleanup-forms in Lisp, and Tim's answer was right on the mark. Use a macro around the form that allocates, binds to a variable, and cleans up, but don't worry about the memory. | It cannot be delayed until the GC starts. Well, what happens at GC time is that memory that is not referenced by anything can be reused for new objects. This is strictly about freeing _memory_ and has absolutely nothing to do with destructors. The objects that GC sees are live objects, not dead ones. There is an exception to this, of course, called finalization. It is code triggered after the GC discovers that there is only one reference to the object, and that is from the finalization. Most Common Lisp implementations also have "weak references", references that are changed to nil when they are the last reference. | I could do this explicitly (and this is the solution recommended by MS | for Java, so I guess there must be some better way ;-), but it seems | ugly and error prone. Yup, it would be in a language without macros and unwind-protect. | Maybe this is a newbie's mistake, but I still don't feel safe to let | the GC handle "resource management" (not just memory management): file | handles, brushes, db connections, etc... that must be released asap | because they are scarce or that must be released in a precise order | (that's the specific problem I'm having). No, don't just feel unsafe, feel _scared_! You're quite right that doing resource management with GC is wrong. It's a pity that C++ and Java conflated the management of memory and other resources, as memory essentially is free and everything else is not, leading to radically different allocation, deallocation, and management strategies for the two kinds of resources. Oh, it just occurred to me that maybe these languages are really based in the assumption that memory is _also_ scarce. Geez, _that's_ a flashback to the 50's! On with your white lab coats and roll in the decks of cards with the Java program from the browser request made last week. Crank up the power to that extra bank of 16K core memory and start the espresso program on the coffee system, too. It's gonna be a _long_ night. This code forgot to deallocate! unwind-protect is your friend here, but most people find that using it gives your code a low-level feel. Let fancy macros like with-open-file does the whole resource management cycle for you, from opening the stream to guaranteeing that it is closed when you leave. You don't even see the memory management involved, of course. That's the bonus. #:Erik -- "When you are having a bad day and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle." -- Unknown