comp.lang.ada
 help / color / mirror / Atom feed
From: "Nick Roberts" <Nick.Roberts@dial.pipex.com>
Subject: Re: newbie Q: storage management
Date: 1997/05/02
Date: 1997-05-02T00:00:00+00:00	[thread overview]
Message-ID: <01bc54f6$09924480$LocalHost@xhv46.dial.pipex.com> (raw)
In-Reply-To: 5k5hif$7r5@bcrkh13.bnr.ca





Kaz Kylheku <kaz@vision.crest.nt.com> wrote in article
<5k5hif$7r5@bcrkh13.bnr.ca>...
> I've looked at the ISO standard and the relevant FAQ's and tutorials, but
I
> still need some discussion or clarification about the management of
objects
> obtained via ``new'', because what I have read so far seemed rather vague
in
> one respect.
> 
> Whose responsibility is it to destroy these objects? The Ada 95 standard
> says that an implementation is permitted to implement garbage collection,
> but not required to do so.
> 
> I know that it is possible to instantiate a generic freeing function for
> explicitly destroying objects. But why is there is this lack of symmetry
in the
> language?  On the one hand, you have a slick ``new''-expression to create
> objects, but the complementary deletion operation is totally obscured.
Does
> this mean that explicit freeing of objects via an instance of
> Unchecked_Deallocation is discouraged (due to the potential creation of
> dangling references)? 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?
> 

In Ada, an object of an access type is defined (by the language) as being
deallocated, in effect, when that type goes out of scope. However, since
the object cannot possibly be dereferenced (used) when its type has gone
out of scope, an Ada compiler need, in practice, do nothing to deallocate
the object: it can just leave the memory used up by the allocation
permanently allocated (until the program terminates).

The Ada compilers that I have used are old and arcane ones (for four-bit
target machines, believe it or not). I gather from recent net conversations
that most Ada compilers these days do not do any automatic memory
reclamation ('garbage collection'), because it is not generally required.
Well, I would agree wholeheartedly that in embedded applications, random
garbage collection would be just a tad impractical; of course, in these
applications, access types (I don't mean 'access all' types) tend not to be
used anyway.

However, I would assert that an Ada compiler which targets a desktop
computer should provide full reclamation, no matter how much extra memory
or time it costs. It seems just too impractical to me that it should do
otherwise.

I would welcome comments on this.

Nick.





  parent reply	other threads:[~1997-05-02  0:00 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-04-29  0:00 newbie Q: storage management Kaz Kylheku
1997-04-30  0:00 ` Samuel A. Mize
1997-04-30  0:00   ` Jon S Anthony
1997-05-02  0:00     ` Samuel A. Mize
1997-05-02  0:00       ` Jon S Anthony
1997-05-03  0:00       ` Robert Dewar
1997-05-05  0:00         ` Samuel A. Mize
1997-05-06  0:00           ` Michael F Brenner
1997-05-06  0:00             ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan
1997-05-07  0:00               ` Kevin Cline
1997-05-07  0:00                 ` John G. Volan
1997-05-07  0:00                   ` John G. Volan
1997-05-07  0:00                     ` Robert Dewar
1997-05-08  0:00                   ` Jon S Anthony
1997-05-08  0:00                 ` Jon S Anthony
1997-05-07  0:00               ` Stephen Posey
1997-05-08  0:00               ` Dynamic binding of packages Nick Roberts
1997-05-08  0:00                 ` John G. Volan
1997-05-07  0:00             ` newbie Q: storage management Jeff Carter
1997-05-07  0:00             ` Robert Dewar
1997-05-09  0:00               ` Robert I. Eachus
1997-05-10  0:00                 ` Robert Dewar
1997-05-06  0:00           ` Robert Dewar
1997-05-06  0:00             ` Robert A Duff
1997-05-08  0:00               ` Jon S Anthony
1997-05-08  0:00                 ` John G. Volan
1997-05-09  0:00                   ` Jon S Anthony
1997-05-09  0:00                     ` John G. Volan
1997-05-13  0:00                       ` Jon S Anthony
1997-05-13  0:00                         ` Robert Dewar
1997-05-09  0:00                 ` Robert A Duff
1997-05-09  0:00                   ` Brian Rogoff
1997-05-10  0:00                     ` Robert A Duff
1997-05-09  0:00                   ` Jon S Anthony
1997-05-10  0:00                     ` Robert A Duff
1997-05-12  0:00                       ` Jon S Anthony
1997-05-10  0:00                   ` Robert Dewar
1997-05-09  0:00                 ` Robert Dewar
1997-05-13  0:00                   ` Jon S Anthony
1997-05-03  0:00       ` Robert Dewar
1997-05-03  0:00         ` Jon S Anthony
1997-05-04  0:00           ` Robert Dewar
1997-05-05  0:00         ` Samuel A. Mize
1997-05-04  0:00       ` Kevin Cline
1997-05-04  0:00         ` Robert Dewar
1997-04-30  0:00   ` kaz
1997-05-02  0:00   ` Samuel A. Mize
1997-05-04  0:00     ` Robert Dewar
1997-04-30  0:00 ` Jon S Anthony
1997-05-02  0:00   ` Robert Dewar
1997-05-04  0:00     ` Kaz Kylheku
1997-05-04  0:00       ` Robert Dewar
1997-04-30  0:00 ` Robert I. Eachus
1997-04-30  0:00 ` Marinus van der Lugt
1997-04-30  0:00   ` Jon S Anthony
1997-05-02  0:00     ` Robert Dewar
1997-05-02  0:00 ` Nick Roberts [this message]
1997-05-03  0:00   ` Robert Dewar
  -- strict thread matches above, loose matches on Subject: below --
1997-05-08  0:00 Jon S Anthony
1997-05-09  0:00 ` Robert Dewar
1997-05-09  0:00   ` Robert A Duff
1997-05-10  0:00     ` Fergus Henderson
1997-05-10  0:00       ` Robert A Duff
1997-05-12  0:00       ` Jon S Anthony
1997-05-13  0:00         ` Robert Dewar
1997-05-10  0:00 ` Fergus Henderson
1997-05-10  0:00   ` Robert Dewar
1997-05-13  0:00   ` Jon S Anthony
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox