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!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: little precision about anonymous access types
Date: Tue, 15 May 2018 16:48:49 -0500
Organization: JSA Research & Innovation
Message-ID: <pdfkk1$pfj$1@franka.jacob-sparre.dk>
References: <edf7b96a-f340-408c-994f-d5aa73b9f2db@googlegroups.com>
 <p8pe94$3pv$1@franka.jacob-sparre.dk> <p8rhjh$e44$1@dont-email.me>
 <42387d28-c983-4e58-9522-815ccd1ad0fb@googlegroups.com>
 <p8unbg$soe$1@franka.jacob-sparre.dk>
 <b0a9cf48-6a6f-4f10-93a7-fd77c427728c@googlegroups.com>
 <6c1e643d-b826-4b8b-b61c-13c56428ed23@googlegroups.com>
Injection-Date: Tue, 15 May 2018 21:48:49 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="26099"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:52365
Date: 2018-05-15T16:48:49-05:00
List-Id: <comp.lang.ada>


"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:6c1e643d-b826-4b8b-b61c-13c56428ed23@googlegroups.com...
> I should ask this in another way: what strategy do you use with 
> user-defined
>storage pools ? I can guess that since the user doesn't have as much
>"metalinguistic" on types and objects as the compiler, there's a limit to 
>how
>much automatic and complex one might for instance,
>build a default storage pool for anonymous access objects.

Allocate/deallocate with a named access type. As you noted, it is impossible 
to deallocate individual objects with anonymous access types.

Note there is an alternative (not recommended by me): use a storage subpool, 
assign the pool to all anonymous access types using pragma 
Default_Storage_Pool, allocate objects from appropriate subpools, and 
deallocate the objects using Unchecked_Deallocate_Subpool when no longer 
needed.

Or you can just avoid using anonymous access types everywhere and forget (as 
much as possible) that they exist. :-)

                            Randy.