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: Mon, 20 Sep 2021 09:35:35 +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="26393"; 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:62785 List-Id: On 2021-09-20 09:05, Niklas Holsti wrote: > On 2021-09-19 14:41, Dmitry A. Kazakov wrote: >> 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. > > Objects left over in a local collection may certainly be freed > automatically, if the implementation has created a local pool for them. > See ARM 13.11 (2.a): "Alternatively, [the implementation] might choose > to create a new pool at each accessibility level, which might mean that > storage is reclaimed for an access type when leaving the appropriate > scope." May or may not. The feature which correctness depends on scopes and lots of further assumptions has no place in a language like Ada. >>> 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. [...] > > Have you actually measured or observed that overhead in some application? How? However you could estimate it from the most likely implementation as a doubly-linked list. You add new element for each allocation and remove one for each deallocation. The elements are allocated in the same pool or in some other pool. Finalization is not time bounded, BTW. Nice? >> 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. > > So there is a possibility of programmer mistake, leading to unintended > finalization of those (now inaccessible) objects. > > However, your semantic argument (as opposed to the overhead argument) > seems to be based on an assumption that the objects "left over" in a > local collection, and which thus are inaccessible, will still, somehow, > participate in the later execution of the program, which is why you say > that finalizing those objects would "corrupt" them. > > It seems to me that such continued participation is possible only if the > objects contain tasks or are accessed through some kind of unchecked > programming. Do you agree? No. You can have them accessible over other access types with wider scopes: Collection_Pointer := new X; Global_Pointer := Collection_Pointer.all'Unchecked_Access; access discriminants etc. As I said, hands off! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de