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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!Hx95GBhnJb0Xc8StPhH8AA.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Sat, 18 Sep 2021 09:49:16 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1d2551f4-8189-44ec-a54d-4a56a672bedcn@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="49930"; posting-host="Hx95GBhnJb0Xc8StPhH8AA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:62771 List-Id: 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