Re: Does memory leak?

[s424@ii.uib.no (Sverre Brubaek)]

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 **-- -