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: Mon, 20 Sep 2021 19:26:19 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Tue, 21 Sep 2021 00:26:21 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="23978"; 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:62795 List-Id: "Dmitry A. Kazakov" wrote in message news:si4ell$1b25$1@gioia.aioe.org... ... >> Given that an object can be allocated in multiple independent pieces, it >> seems unlikely that what you want will be provided. > > Such implementations would automatically disqualify the compiler. > Compiler-generated piecewise allocation is OK for the stack, not for user > storage pools. If someone wants to require contigious allocation of objects, there should be a representation attribute to specify it. And there should not be an nonsense restrictions on records with defaulted discriminants unless you specify that you require contiguous allocation. There is no good reason to need that for 99% of objects, why insist on a very expensive implementation of slices/unconstrained arrays unless it's required?? ... > No, it is about the overhead of maintaining "collections" associated with > an access type in order to call Finalization for all members of the > collection. How else would you ensure that Finalize is always called on an allocated object? Unchecked_Deallocation need not be called on an allocated object. The Ada model is that Finalize will ALWAYS be called on every controlled object before the program ends; there are no "leaks" of finalization. Otherwise, one cannot depend on finalization for anything important; you would often leak resources (especially for simple kernels that don't try to free unreleased resources themselves). Randy.