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:19:38 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Tue, 21 Sep 2021 00:19:39 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="23797"; 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:62794 List-Id: There is: Restriction No_Controlled_Types. - Randy "Dmitry A. Kazakov" wrote in message news:si45ls$1goa$1@gioia.aioe.org... > On 2021-09-17 23:17, Niklas Holsti wrote: >> On 2021-09-17 23:39, Dmitry A. Kazakov wrote: >>> On 2021-09-17 21:46, Simon Wright wrote: >>>> "Dmitry A. Kazakov" writes: >>>> >>>>> Nope, especially because the issue with X'Address being unusable for >>>>> memory pool developers is a long standing painful problem that need to >>>>> be resolved. That will never happen until a measurable group of people >>>>> start asking questions. So you are doubly welcome. >>>> >>>> There are two attributes that we should all have known about, >>>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2] >>>> (storage units, I think, introduced in 2017) >>> >>> They are non-standard and have murky semantics I doubt anybody really >>> cares about. >>> >>> What is needed is the address passed to Deallocate should the object be >>> freed = the address returned by Allocate. Is that too much to ask? >> >> That is already required by RM 13.11(21.7/3): "The value of the >> Storage_Address parameter for a call to Deallocate is the value returned >> in the Storage_Address parameter of the corresponding successful call to >> Allocate." > > You missed the discussion totally. It is about X'Address attribute. > > The challenge: write pool with a function returning object allocation time > by its pool-specific access type. > >>> BTW, finalization lists (#2) should have been removed from the language >>> long ago. >> >> Huh? Where does the RM _require_ finalization lists? > > 7.6.1 (11 1/3) > >> I see them mentioned here and there as a _possible_ implementation >> technique, and an alternative "PC-map" technique is described in RM 7.6.1 >> (24.r .. 24.t). > > I don't care about techniques to implement meaningless stuff. It should be > out, at least there must be a representation aspect for turning this mess > off. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de