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.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx03.iad.POSTED!not-for-mail
From: Brad Moore <brad.moore@shaw.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: newbie: can't read fast enough... :-)    memory leaks...
References: <479b2efe-0238-4b2a-8b05-cb1a0b4a57e5@googlegroups.com>
 <1409739464.7121.235.camel@obry.net> <hjSNv.114789$Fo3.103404@fx09.iad>
 <lu8ti4$lqq$2@dont-email.me> <WB_Nv.132587$oe6.88682@fx29.iad>
In-Reply-To: <WB_Nv.132587$oe6.88682@fx29.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <dG%Nv.150343$Hb3.42504@fx03.iad>
NNTP-Posting-Host: 68.145.219.148
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: 1409845001 68.145.219.148 (Thu, 04 Sep 2014 15:36:41 UTC)
NNTP-Posting-Date: Thu, 04 Sep 2014 15:36:41 UTC
Date: Thu, 04 Sep 2014 09:36:41 -0600
X-Received-Bytes: 2885
X-Received-Body-CRC: 1321364385
X-Original-Bytes: 2803
Xref: number.nntp.dca.giganews.com comp.lang.ada:188866
Date: 2014-09-04T09:36:41-06:00
List-Id: <comp.lang.ada>

On 2014-09-04 8:23 AM, Brad Moore wrote:
> On 2014-09-03 11:32 PM, Jeffrey Carter wrote:
>> On 09/03/2014 09:57 PM, Brad Moore wrote:
>>>
>>>       declare
>>>          type String_Access is access String;
>>>          A, B : String_Access;
>>>       begin
>>>          A := new String'("String 1");
>>>          B := new String'("String 2");
>>>          ... -- Operate on the data.
>>>       end;
>>>       -- A and B are automatically freed here because the String_Access
>>>       -- is finalized since the scope of the declaration of the access
>>>       -- type is being exited, and finalizing an access type also
>>>       -- finalizes its collection (allocated objects designated by that
>>>       -- type).
>>>
>>> This is a nice way to free up a bunch of objects that are no longer
>>> needed, if
>>> it can be guaranteed that the objects are only needed in a nested
>>> scope. I like
>>> this better than garbage collection, because the
>>> deallocation occurs more consistently, when and where it is needed.
>>> I view this as being less error prone, if one is able to take
>>> advantage of this
>>> approach.
>>
>> Recent comments here in another thread indicate that this only works if
>> 'Storage_Size is defined for the access type.
>>
>
>
> That doesn't appear to be correct.

Looking deeper, yes, the objects of access type are finalized when the 
access type goes out of scope, but it is implementation defined whether 
the storage for the objects is reclaimed.

I wonder how many implementations are out there that do not have a 
default storage pool that reclaims the storage of a collection of an 
nested access type when the master associated with of the access type 
declaration is exited.

I'm pretty sure that GNAT does for Windows and Linux, but perhaps they 
have a minimalist runtime for certain targets where this is not needed 
or desired?