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,b307bd75c8071241
X-Google-Attributes: gid103376,public
From: kaz@.crest.nt.com (Kaz Kylheku)
Subject: Re: newbie Q: storage management
Date: 1997/04/30
Message-ID: <5k85tm$1jh@bcrkh13.bnr.ca>#1/1
X-Deja-AN: 238480975
References: <5k5hif$7r5@bcrkh13.bnr.ca> <336754A0.41C6@magellan.bgm.link.com>
Organization: Prism Systems Inc.
Newsgroups: comp.lang.ada
Date: 1997-04-30T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <336754A0.41C6@magellan.bgm.link.com>,
Samuel A. Mize <smize@magellan.bgm.link.com> wrote:

>It's the programmer's responsibility to destroy individual objects with
>Unchecked_Deallocation.

Okay, that's basically what I wanted to know. Thank you (and others) very much.

>Note that dynamic storage is often useful WITHOUT reclamation.  For instance,
>if you read some kind of dictionary into your program from a file, you might
>put it into a linked list so you aren't tied to a specific table size, even
>though you will never delete any of the terms.

Yes, this is true. Another common example is compilers which never deallocate
their symbol table data structures, syntax trees and the like. It's not
uncommon to not even implement deletion operations from such structures.
The idea is that the compiler is short lived, and works on reasonably
small sets of data.

>>Is it the reponsibility of the language implementation to
>> automagically detect when an object is no longer reachable and do the
>> appropriate deallocation, even if garbage is not collected?
>
>Nope.  You can chew up the entire system's memory with this program:
>
>  procedure Just_Kill_Me is
>    type integer_access is access integer;
>    x: integer_access;
>  begin
>    loop
>       x := new integer;
>    end loop;
>  end Just_Kill_Me;
>
>Is this the best language-design tradeoff?  well, yes and no, respectively.
>It depends on what you want to use the language for, and how you want to
>use it.

Isn't it funny how deletion is usually more complicated than creation? I mean
in general. Pick a data structure at random, and chances are that its deletion
algorithm is more difficult than insertion. In file systems, deletion of files
seems to pose more problems than file creation.  (Consider, e.g., that SunOS
updates inodes synchronously when deleting files, to forestall the possibility
of irrecoverable corruption, but when creating files it does not act this way).
Inserting into a binary search tree, balanced or not, is a heck of a lot easier
than deleting.  And even in simple linked lists, removal of nodes can be harder
than insertion.

In some way it makes perfect sense that Ada doesn't provide a handy ``delete''
to accompany the ``new'', since a lot more care is required when an object
is being deleted than when it's being created.