Subject: Re: Allocating on the stack and *only* on the stack
From: Erik Naggum <>
Date: 12 Dec 2000 14:54:07 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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

  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.

  "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