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

["Randy Brukardt" <randy@rrsoftware.com>]

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

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.

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.

                          Randy.