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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!news.stack.nl!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: newbie: can't read fast enough... :-)    memory leaks...
Date: Thu, 04 Sep 2014 17:55:34 +0200
Organization: A noiseless patient Spider
Message-ID: <lua21m$9c0$1@dont-email.me>
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>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 4 Sep 2014 15:55:34 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
 logging-data="9600"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX1/1WSX8hA5OX6HlDpXWltlV5VCL/7j8bWs="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <WB_Nv.132587$oe6.88682@fx29.iad>
Cancel-Lock: sha1:z5hcW2pDhWlh5WkfyasPH11fiu0=
Xref: number.nntp.dca.giganews.com comp.lang.ada:188868
Date: 2014-09-04T17:55:34+02:00
List-Id: <comp.lang.ada>

On 04.09.14 16:23, 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.
>
> In the latest GNAP GPL, the following program outputs;
>
> Finalizing
> Finalizing
> Exited Block

However, only Finalize is run, which apparently is
not triggering deallocation. The following makes me
observe a leak:

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Finalization; use Ada;
procedure Test_Deallocation is

    procedure Block is
       type T is new Finalization.Limited_Controlled with null record;
       overriding procedure Finalize   (Object : in out T);
       overriding procedure Finalize (Object : in out T) is
       begin
          Put_Line ("Finalizing ");
       end Finalize;

       type T_Access is access T;
       T1, T2 : T_Access;
    begin
       T1 := new T;
       T2 := new T;
    end Block;

begin
    loop
       Block;
       Put_Line ("Exited Block");
       delay 0.2;
    end loop;
end Test_Deallocation;