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 23:32:25 +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 A8in9cXKGOCL1FMamuaBBAHPIKd6hmocTIRfOAKTX27LBvs3g6 Cancel-Lock: sha1:0HQMONN2X27wQ0cjLY3uk2ReqhM= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:21738 Date: 2014-08-13T23:32:25+03:00 List-Id: On 14-08-13 01:34 , Adam Beneschan wrote: > 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 > requirement. I believe I agree. (I don't really understand why the RM makes these statements about the "collection" as an "object". I guess these statements connect to some general RM statements about objects, but I don't know which statements the latter are.) > 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 for the pool does get reclaimed when the block is > left. (13.11(18)) Oh yes, that's the trick. Which gives a better answer to the OP's question, doesn't it? >> 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. It may be that I had a Storage_Size spec in that test of DEC Ada, I don't clearly remember. > I can't find anything explicit like this in the Ada 83 RM, even if > Storage_Size is specified. There's a kind of "exception proves the rule" in 4.8 (sorry, I don't see the paragraph number): "2. The pragma CONTROLLED informs the implementation that automatic storage reclamation must not be performed for objects designated by values of the access type, except upon leaving the innermost block statement, subprogram body, or task body that encloses the access type declaration, or after leaving the main program." The part "except upon leaving ..." suggests that storage is (or at least may be) reclaimed when the access type declaration goes out of scope. But you are right, it is not a requirement, probably it is just the traditional RM permission to collect garbage. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .