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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.66.248.37 with SMTP id yj5mr501862pac.16.1407882854888;
        Tue, 12 Aug 2014 15:34:14 -0700 (PDT)
X-Received: by 10.50.114.161 with SMTP id jh1mr757077igb.17.1407882854693;
 Tue, 12 Aug 2014 15:34:14 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h18no12311795igc.0!news-out.google.com!px9ni588igc.0!nntp.google.com!h18no19155065igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 12 Aug 2014 15:34:14 -0700 (PDT)
In-Reply-To: <c4vgm3Fc85cU1@mid.individual.net>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=66.126.103.122;
 posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq
NNTP-Posting-Host: 66.126.103.122
References: <d4137ad0-148a-4cf9-a6d8-c36e60ae7c9f@googlegroups.com>
 <a93a7da9-e3cc-410f-a7dc-f81ea8c179e5@googlegroups.com>
 <DktGv.521654$Ro3.320929@fx13.iad>
 <4dba71e0-30c9-4e16-9edb-4e8b43acc2ab@googlegroups.com>
 <c4vgm3Fc85cU1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b94a1432-123d-478e-adce-06432eccf4d5@googlegroups.com>
Subject: Re: A simple question about the "new" allocator
From: Adam Beneschan <adambeneschan@gmail.com>
Injection-Date: Tue, 12 Aug 2014 22:34:14 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:21695
Date: 2014-08-12T15:34:14-07:00
List-Id: <comp.lang.ada>

On Tuesday, August 12, 2014 2:53:36 PM UTC-7, Niklas Holsti wrote:

> It seems to me that if an access type is declared in a block, then
> completion of the block should by these rules cause the collection of
> that access type, being an "object implicitly declared" in the block, to
> cease to exist. For ordinary objects explicitly declared in a block, I
> certainly expect the object's storage to be reclaimed when the object
> ceases to exist on block exit; why should this not apply also to a
> collection object, even if its declaration is implicit?

I see your point.  But unless I've missed something, it's not an RM require=
ment.

However, if Storage_Size is specified for an access type, I think that the =
program does have to allocate a pool just for that type, and the storage fo=
r the pool does get reclaimed when the block is left.  (13.11(18))  The dif=
ference is that when Storage_Size is specified, the expectation is that the=
 program will allocate a contiguous block of memory of that size to be used=
 for allocations for that access type, and that storage block can simply be=
 reclaimed all at once.  If Storage_Size is not specified, there won't be a=
ny such contiguous block.=20

> I have not found an explicit requirement on reclaiming the storage of a
> collection in the Ada 2012 RM. As I remember, the Ada 83 RM had some
> more explicit text about this, and I remember testing that it worked
> (the collection's storage was reclaimed) with DEC Ada on a VAX.

I can't find anything explicit like this in the Ada 83 RM, even if Storage_=
Size is specified.

                            -- Adam