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:18:31 -0500 Organization: JSA Research & Innovation Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Injection-Date: Tue, 21 Sep 2021 00:18:32 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="23792"; 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:62793 List-Id: Janus/Ada uses chains for everything; there is no attempt to do anything else. They make dealing with partially initialized objects (when some initialization fails) much easier, and are strongly related to the lists of allocated memory that Janus/Ada uses anyway. It's easy to deal with a stand-alone controlled object, but when you have components of dynamic components of dynamically sized object and have to deal with failures and allocated objects, the headaches just aren't worth it (IMHO). The cost is insignificant unless you actually have controlled objects, so you only pay for what you use (to steal a line from a commercial that runs far too often in the US). Randy. "Dmitry A. Kazakov" wrote in message news:si2ud7$fv2$1@gioia.aioe.org... > 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? > > BTW, finalization lists (#2) should have been removed from the language > long ago. They have absolutely no use, except maybe for debugging, and > introduce huge overhead. The semantics should have been either > Unchecked_Deallocation or compiler allocated objects/components may call > Finalize, nothing else. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de