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=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.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" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Sat, 2 Oct 2021 23:33:13 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Sun, 3 Oct 2021 04:33:14 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="3028"; 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; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:62927 List-Id: "Dmitry A. Kazakov" wrote in message news:sj9blb$1srp$1@gioia.aioe.org... > On 2021-10-02 11:06, Randy Brukardt wrote: ... >> That's again not safe in any sense. You shouldn't need to worry about >> whether some abstraction that you use uses finalization, especially as >> you >> can't know if someone adds it later. > > Why compiler assisted bookkeeping is safe for subpools, but unsafe as a > stand-alone mechanism? There is no such stand-alone mechanism, and there cannot be one -- such bookkeeping requires an object to store the bookkeeping into, and there is none in the normal case. The only place to put such a thing is with the access type, thus the collection mechanism. Pools are 100% user-defined, and that can't be changed at this late date. (And if you did try to change it, you'd end up with something almost the same as subpools anyway.) ... > Sure, but again. there is a paramount use case that requires dynamic > elaboration of tagged types, i.e. the relocatable libraries. You cannot > ban them I suppose, but you certainly don't have to use them. That sort of thing is nonsense that simply makes programs more fragile than they have to be. I just had a problem with Debian where some older programs compiled with GNAT refused to run because an update had invalidated some library. Had to dig out the source code and recompile. ... > you cannot forbid tagged extensions declared in a relocatable library. Of course you can. The only thing you need to be compatible with is a C interface, which is the only thing you need to interface to existing libraries that you can't avoid. >So getting rid of nesting tagged types will ease nothing. The problem is tagged types not declared at the library level. Relocatable librarys are still library level (they have their own global address space). So there wouldn't be the same problems as a tagged type declared in a subprogram (which requires carrying around a static link or display, and multiple part tags). Randy.