From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!Hx95GBhnJb0Xc8StPhH8AA.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Sun, 19 Sep 2021 13:41:00 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="28298"; posting-host="Hx95GBhnJb0Xc8StPhH8AA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:62779 List-Id: On 2021-09-19 12:36, Niklas Holsti wrote: > On 2021-09-18 19:19, Dmitry A. Kazakov wrote: >> On 2021-09-18 17:59, Niklas Holsti wrote: >> >>> So you want a way to specify that for a given access type, although >>> the accessed object type has a Finalize operation or needs >>> finalization, the objects left over in the (at least conceptually) >>> associated collection should _not_ be finalized when the scope of the >>> access type is left? >> >> Exactly, especially because these objects are not deallocated, as you >> say they are left over. If they wanted GC they should do that. If they >> do not, then they should keep their hands off the objects maintained >> by the programmer. >> >>> To me it seems a risky think to do, subverting the normal semantics >>> of initialization and finalization. >> >> Quite the opposite, it is the collection rule that subverts semantics >> because objects are not freed, yet mangled. > > Local variables declared in a subprogram are also not explicitly freed > (deallocated), yet they are automatically finalized when the subprogram > returns. Local objects are certainly freed. Explicit or not, aggregated or not, is irrelevant. > My understanding of Ada semantic principles is that any object that is > initialized should also be finalized. IFF deallocated. An application that runs continuously will never deallocate, HENCE finalize certain objects. > Has this feature of Ada caused you real problems in real applications, > or is it only a point of principle for you? 1. It is a massive overhead in both memory and performance terms with no purpose whatsoever. I fail to see where that sort of thing might be even marginally useful. Specialized pools, e.g. mark-and-release will deploy their own bookkeeping, not rely on this. 2. What is worse that a collection is not bound to the pool. It is to an access type, which may have a narrower scope. So the user could declare an unfortunate access type, which would corrupt objects in the pool and the pool designer has no means to prevent that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de