Subject: Re: Why Arc isn't especially OO
From: Erik Naggum <>
Date: Mon, 17 Dec 2001 06:36:14 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Alexander Kjeldaas <>
| On the other hand, setting up a memory area that you allocate all objects
| from (often called "areas" in the C/C++ world), and tearing it down when
| you are finished with the request is a well known technique which is used
| all over the place where server programming happens.  It is an extremely
| efficient way of handling this issue, and I think it would be nice to
| have some language support for this.

  You need explicit allocation to make this work.  Common Lisp does not
  have explicit allocation.  C++ does, and therefore needs this dubious
  "feature".  There is in fact _no_ language support in Common Lisp for
  _any_ form of allocation or deallocation.  Think about it.

  In Common Lisps with a generational scavending garbage collector, such
  "areas" would amount to a "private" newspace, the GC'ing of which would
  copy live objects somewhere else before it got torn down.  Because the
  whole language does allocation at will, the amount of control that would
  benefit from such areas being torn down as an inexpensive operation is
  simply not there.  Whether you garbage collect a private newspace or the
  global newspace thus has no impact on performance (other than to copy any
  living objects once).

| I would prefer a general solution that works for all allocation, for all
| objects, also allocation done in a library not written with GC quirks in
| mind.  But I agree that resourcing is a good engineering solution that
| overcomes GC problems.

  Resourcing is not about "overcoming GC problems".  Their main use is to
  avoid allocating space that is usually freed immediately.  In effect,
  resources are in Common Lisp what "areas" are in C++: privately managed
  allocation.  Normally, however, allocated resources are discarded when
  GC happens, because they are maintained using weak pointers.  This is a
  useful technique only when one expects allocating a lot of garbage of the
  exact same type.

  It appears that the desire to control memory allocation manually is
  almost a one-bit mental state.  When I recently argued in a C group that
  calling free in short-lived or low-garbage applications was a waste of
  programmer brain cycles, one fairly irrational dude jumped on me and got
  nearly hysterical that I could even suggest such a thing.  Explicit calls
  to free was to him the very mark of good programmer, and lack of which
  the mark of the devi.  He argued that some broken version of Windows did
  not free memory allocated by a process unless expliciet calls to free
  were made all of the program, and has yet to realize that the goals of
  (manual) memory management may be obtained by automatic means.  I, on the
  other hand, consider manual memory management to be _really_ stupid, and
  the desire to obtain control over this part of program development by
  forcing every allocation and deallocation to be manual as sheer lunacy.
  I have 15 years of experience writing C applications where manual memory
  allocation was never a problem.  Now it is.  My bit has been inverted.

  The past is not more important than the future, despite what your culture
  has taught you.  Your future observations, conclusions, and beliefs are
  more important to you than those in your past ever will be.  The world is
  changing so fast the balance between the past and the future has shifted.