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: 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.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: A simple question about the "new" allocator Date: Wed, 13 Aug 2014 00:53:36 +0300 Organization: Tidorum Ltd Message-ID: References: <4dba71e0-30c9-4e16-9edb-4e8b43acc2ab@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net ZQXOS/kYu9SSzGSR00J21QFu6HlTm3LXb5gX8T+a7xiSpuzsaF Cancel-Lock: sha1:pyPk0ZzybBkagQPqI2AHZ1hp9MM= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <4dba71e0-30c9-4e16-9edb-4e8b43acc2ab@googlegroups.com> Xref: news.eternal-september.org comp.lang.ada:21693 Date: 2014-08-13T00:53:36+03:00 List-Id: On 14-08-12 22:10 , Adam Beneschan wrote: > On Tuesday, August 12, 2014 11:49:03 AM UTC-7, Shark8 wrote: >> >>> procedure main is >>> begin >>> loop >>> declare >>> Test : access Positive := new Positive; >>> begin >>> null; >>> end; >>> end loop; >>> end main; >> >> I /think/ you can do it with a type definition on the inner-block: >> >> declare >> Type Inner_Access is not null access positive; >> Test : Inner_Access := new Positive; >> begin >> null; >> end; >> >> The reason is that leaving the nested-block's scope should force the >> deallocation of all Inner_Access types if I'm remembering the RM correctly. > > No, I don't think that's correct. When an access type is declared > in a nested block, all objects allocated using that access type (and > not already deallocated) are *finalized*, but deallocation isn't > required. I don't see anything in the RM that says the storage > must be reclaimed. Perhaps there is at least a suggestion of this? RM 7.6.1(11.1/3) and 7.6.1(11.2/3) say that "Each nonderived access type T has an associated collection, which is the set of objects created by allocators of T, or of types derived from T. [...] The collection of an access type is an object implicitly declared at the following place: [...] For a named access type, the first freezing point of the type." RM 7.6.1(11/3) says that "The finalization of a master performs finalization of objects created by declarations in the master [...] After the finalization of a master is complete, the objects finalized as part of its finalization cease to exist, ...". 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 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. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .