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.216.233 with SMTP id ot9mr634336pac.38.1407886871053; Tue, 12 Aug 2014 16:41:11 -0700 (PDT) X-Received: by 10.50.142.104 with SMTP id rv8mr696164igb.11.1407886870949; Tue, 12 Aug 2014 16:41:10 -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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!h18no19180330igc.0!news-out.google.com!px9ni620igc.0!nntp.google.com!h18no12326961igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 12 Aug 2014 16:41:10 -0700 (PDT) In-Reply-To: <5c104779-8f67-44f2-96be-5ad2f627df2c@googlegroups.com> 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: <4dba71e0-30c9-4e16-9edb-4e8b43acc2ab@googlegroups.com> <5c104779-8f67-44f2-96be-5ad2f627df2c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <15e09ab5-804e-4070-9ad2-46dc18d17505@googlegroups.com> Subject: Re: A simple question about the "new" allocator From: Adam Beneschan Injection-Date: Tue, 12 Aug 2014 23:41:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5419 X-Received-Body-CRC: 2112530967 Xref: news.eternal-september.org comp.lang.ada:21699 Date: 2014-08-12T16:41:10-07:00 List-Id: On Tuesday, August 12, 2014 4:14:16 PM UTC-7, sbelm...@gmail.com wrote: > On Tuesday, August 12, 2014 6:34:14 PM UTC-4, Adam Beneschan wrote: >=20 > >=20 >=20 > > 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 storag= e for the pool does get reclaimed when the block is left. (13.11(18)) The= difference 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 simpl= y be reclaimed all at once. If Storage_Size is not specified, there won't = be any such contiguous block.=20 >=20 > >=20 >=20 >=20 >=20 >=20 >=20 > Since we are already lawyering up, is it not true that >=20 >=20 >=20 > procedure main is=20 >=20 > begin=20 >=20 > loop=20 >=20 > declare=20 >=20 > Test : access Positive :=3D new Positive;=20 >=20 > begin=20 >=20 > null;=20 >=20 > end;=20 >=20 > end loop;=20 >=20 > end main; >=20 >=20 >=20 > is (advised to be) equivalent to this: >=20 >=20 >=20 > procedure main is=20 >=20 > begin=20 >=20 > loop=20 >=20 > declare >=20 > p : Some_Default_Pool; >=20 > type T is access Positive; >=20 > for T'Storage_Pool use p; >=20 > Test : T :=3D new Positive;=20 >=20 > begin=20 >=20 > null;=20 >=20 > end;=20 >=20 > end loop;=20 >=20 > end main; >=20 >=20 >=20 > based on 13.11~25.4/2 ("Otherwise, a default storage pool should be creat= ed at the point where the anonymous access type is elaborated") and then co= nsequently reclaimed when p goes out of scope? There's nothing that says *any* storage pool has to have its memory reclaim= ed, ever. Suppose you declare your own: declare type My_Storage_Pool (Size : Storage_Count) is new Root_Storage_Poo= l with record ... end record; ... override Allocate, Deallocate, Storage_Size, Initialize, Finali= ze Pool : My_Storage_Pool; type T is access Positive; for T'Storage_Pool use Pool; begin ... end; So when Pool goes out of scope, you'd think the memory used by Pool will be= reclaimed, right? Not necessarily. Nothing says Pool has to have the memory used for allocat= ion as part of the object. The Initialize routine could allocate a byte ar= ray on the normal heap. If this byte array isn't deallocated by My_Storage= _Pool's Finalize routine, then the storage won't be reclaimed. This isn't really relevant to the real world, since hopefully nobody would = write My_Storage_Pool like that. The point, here, is that you and others s= eem to be trying to infer an RM requirement (or "Implementation Advice"-typ= e strong suggestion) based on some passages here and there, but in this cas= e you're basing it on an assumption that isn't true. That is, you're assum= ing that a "storage pool" that's declared in a local scope will have its st= orage reclaimed when the scope is exited. I'm trying to demonstrate that t= his assumption is false, and thus your logic rests on a false assumption. None of this says that you shouldn't expect the storage to be reclaimed, an= d you're certainly within your rights to complain to your compiler vendor i= f it isn't. But I just don't see an RM requirement. To me, the situation = is what it's always been, since Ada 83: a program that does its own allocat= ion is responsible for deallocating things itself; and, with the exception = of specifying Storage_Size, in which case the program is expected to reserv= e a block of memory, there's no magic trick to get Ada to deallocate things= for you. At least, there's no guaranteed, portable magic trick. -- Adam