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, 27 Sep 2021 23:31:34 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Tue, 28 Sep 2021 04:31:35 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="29606"; 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:62845 List-Id: "Dmitry A. Kazakov" wrote in message news:sibvcr$1ico$1@gioia.aioe.org... > On 2021-09-21 02:26, Randy Brukardt wrote: >> "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. > > It would be difficult, because the types are declared prior to pools. That > is when object layout does change. > > If the layout does not then you need no attribute. > > You can always run a mock allocation to compute overall size and offsets > to the pieces and then do one true allocation. And with stream attributes > you need to implement introspection anyway. So this might have been an > issue for Ada 83, but now one can simply require contiguous allocation in > pools. > >> And there should not be an >> nonsense restrictions on records with defaulted discriminants unless you >> specify that you require contiguous allocation. > > You can keep the object layout. It is only the question of "trolling" the > pool, no how objects are represented there. > >>> 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? > > I would not, because it is plain wrong. Finalize must be called for each > *deallocated* object. Deallocation is irrelevant. Finalization is called when objects are about to be destroyed, by any method. Otherwise, you do not have watertight finalization, and it is near impossible to use it for anything important. Randy.