From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,13d6cd0af0d0d769
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Does memory leak?
Date: 1995/03/30
Message-ID: <EACHUS.95Mar30172902@spectre.mitre.org>#1/1
X-Deja-AN: 100540674
references: <3kopao$ekg@nef.ens.fr> <3kql6c$1b3@porte-de-st-ouen.ics.uci.edu>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1995-03-30T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <hbaker-2903952208230001@192.0.2.1> hbaker@netcom.com (Henry Baker) writes:

   In article <3l6gf6$h05@theopolis.orl.mmc.com>, Theodore Dennison
   <dennison@escmail.orl.mmc.com> wrote:

   > I mean, if you don't deallocate what you allocate, your program will
   > leak memory no matter what language it is written in. This isn't an Ada
   > issue, it's an issue of sloppy coding.

 > Not necessarily true.  I've written lots and lots of Lisp programs, and
 > I think that I forgot to deallocate in almost all of them.  They worked
 > just fine.

 > (Of course I'm being facetious.  Lisp doesn't have a deallocate primitive,
 > because it has an automatic garbage collector, just like Modula and Eiffel.
 > Furthermore, garbage collection can't collect stuff that is still linked
 > to live objects, so you can still get a 'leak' this way.)

    The truth is somewhere in between, but a lot closer to Ted's
position.  It is ALWAYS sloppy coding to leave garbage lying around.
In some languages--including LISP and Ada 95--it is possible to get
the compiler/language to do most of the work for you, but it is still
the programmer's responsibility to see that garbage is visible as
such.

    In LISP, most garbage is automatically collected, but pathological
misuse of memory can slow performance to a crawl, and leaving pointers
to memory no longer in use lying around can quickly run you out of
memory.

    In Ada, most allocation and reclamation is from the user's point
of view automatically controlled by the compiler.  With a bit of
attention to scope entries and exits you can manage quite elaborate
structures without ever having to call an instance of
Unchecked_Deallocation.  Reorganize the code slightly and all of those
allocators are at the outermost scope level and your program dies a
nasty death.

    I find that memory management in both is about the same level of
effort.  A little bit of thinking about the real storage model is a
constant necessity, but it is very seldom an issue you spend any time
worring about.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...