Re: Custom Storage Pool questions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2021-09-18 11:03, Niklas Holsti wrote:
> On 2021-09-18 10:49, Dmitry A. Kazakov wrote:
>> 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" <mailbox@dmitry-kazakov.de> 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.
> 
> 
> Sure, I understand that the address returned by Allocate, and passed to 
> Deallocate, for an object X, is not always X'Address, and that you would 
> like some means to get the Allocate/Deallocate address from (an access 
> to) X. But what you stated as not "too much to ask" is specifically 
> required in the RM paragraph I quoted. Perhaps you meant to state 
> something else, about X'Address or some other attribute, but that was 
> not what you wrote.

I wrote about attributes, specifically GNAT-specific ones used in the 
blog to calculate the correct address. "Too much to ask" was about an 
attribute that would return the object address directly.

> 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.

And anyway, all this equally applies to X'Address.

>>>> 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)
> 
> 
> RM (2012) 7.6.1 (11.1/3) says only that objects must be finalized in 
> reverse order of their creation. There is no mention of "list".

It talks about "collection."

> Then your complaint seems to be about something specified for the order 
> of finalization, but you haven't said clearly what that something is.

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de