Re: On absurdity of collections 7.6.1 (11.1/3)

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

On 2021-10-01 03:37, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sj3r7l$pla$2@gioia.aioe.org...
> ...
>> Yes, every general access type that permits instantiation of
>> Unchecked_Dellocation must indicate the target object's pool, directly,
>> e.g. per fat pointer, or indirectly by some other schema. I see nothing in
>> RM that allows a different implementation. But it is could be a bug by
>> omission and I am not a language lawyer anyway.
> 
> Each access type has only one pool, and all allocations and deallocations
> for that access type use that pool. You can see at RM 13.11(13) that you can
> retrieve the storage pool of T, that wouldn't be possible if it could have
> multiple pools. Allocation for T uses T'Storage_Pool (RM 13.11(16)), and
> deallocation for T also uses T'Storage_Pool (13.11.2(9/3) - I see this
> wording isn't as clear as it could be, but "the storage_pool" here is the
> one for the type T. It is clear, however, from 13.11.2(16/3) that it is
> erroneous to deallocate an object for some other pool than the pool of the
> access type passed to the instance of Unchecked_Deallocation.

At least instantiations of Unchecked_Deallocation should be illegal with 
general access.

> Surely no one would expect the pool to be associated with the object -- it
> would be impossible to interface to C or most other languages that way. Note
> that GNAT insists that all access types are C-compatible.

Normally you cannot allocate C objects intended to be freed from C using 
Ada allocator. This is a common mistake of binding designers which 
promptly crashes the program.

But I see no problem here, especially because the access type must have 
C convention anyway.

> As I've said repeatedly, if you want the behavior of multiple pools with a
> single access type, you have to use the subpool mechanism somehow.

Honestly I still try to find a useful case for subpools. It is nothing 
that could not be easily implemented using existing pools or might help 
fighting off collections etc.

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