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: s424@ii.uib.no (Sverre Brubaek)
Subject: Re: Does memory leak?
Date: 1995/04/05
Message-ID: <3ltkch$8vl@alf.uib.no>#1/1
X-Deja-AN: 100266050
distribution: world
references: <3kopao$ekg@nef.ens.fr> <3kql6c$1b3@porte-de-st-ouen.ics.uci.edu>
 <3kuba0$8kd@gnat.cs.nyu.edu> <3l6gf6$h05@theopolis.orl.mmc.com>
 <hbaker-2903952208230001@192.0.2.1> <3ls2ku$qls@hacgate2.hac.com>
organization: Institutt for Informatikk UIB Norway
newsgroups: comp.lang.ada
Date: 1995-04-05T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <3ls2ku$qls@hacgate2.hac.com>, jbaker@thor.tu.hac.com (John Baker) writes:
|> Henry Baker (hbaker@netcom.com) wrote:
|> : In article <3l6gf6$h05@theopolis.orl.mmc.com>, Theodore Dennison
|> : <dennison@escmail.orl.mmc.com> wrote:
|> 
|> : > Perhaps I'm missing something here...what exactly is wrong with using 
|> : > UNCHECKED_DEALLOCATION?
|> : > 
|> : > 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 Lisp i programmed in (symbolics) had a really nice feature --
|> allocation to *named* areas of memory.  You could allocate
|> objects with differing life spans in different areas and then
|> (at the appropriate time), wipe a whole named area and start over
|> without having to destroy the objects individually.  Very fast
|> and easy to control.  I'd like to see a feature like that in C++
|> and ADA.
|> 
|> JB

I'll just quote from the RM:

  13.11 Storage Management

  (1)
     Each access-to-object type has an associated storage pool. The storage 
     allocated by an allocator comes from the pool; instances of 
     Unchecked_Deallocation return storage to the pool. Several access types 
     can share the same pool. 
  (2)
     A storage pool is a variable of a type in the class rooted at 
     Root_Storage_Pool, which is an abstract limited controlled type. By 
     default, the implementation chooses a standard storage pool for each 
     access type. The user may define new pool types, and may override the 
     choice of pool for an access type by specifying Storage_Pool for the type. 

I'd say this looks pretty much like the feature you wanted.

P.S. Although it has been said before, Ada is _not_ spelled in capitals.

-- 
+-------------------------------Sverre Brubaek--------------------------------+
| e-mail s424@brems.ii.uib.no         | s-mail Stoeletorget 10, 5003 bergen   |
| v-mail (+47) 55 96 24 81            | www http://brems.ii.uib.no/~s424/     | 
+-------------------------------------+---------------------------------------+
  - --** Team os/2 **-- - - - --** Team Ada **-- - - - --** MNIF-stud **-- -