Re: Ada containers and custom allocators

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

On Wed, 09 Jan 2008 10:29:46 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 8 Jan 2008 17:54:44 -0600, Randy Brukardt wrote:
>>
>>> But it isn't valuable enough to force every user
>>> of a container to define a storage pool (since there is no name for a
>>> standard storage pool).
>>
>> That always wondered me, why there is no name for. Especially because the
>> default storage pool can be obtained anyway:
>>
>> type Some_Ptr is access Integer; -- Goes to the default storage pool
>> package Foo is new Boo (Some_Ptr'Storage_Pool);
> 
> The compiler is not required to use the same storage pool for all
> types.  Therefore, the concept "THE default pool" does not exist.
> 
> Some_Ptr'Storage_Pool might be a special pool tuned for the fact that
> Size_In_Storage_Elements = 4 and Alignment = 4.  Allocate could
> add 4 to a known-aligned pointer, and ignore the
> Size_In_Storage_Elements and Alignment parameters.
> 
> If Boo uses this pool for something other than Integer,
> it might not work.

Which is broken then. Because it does not fulfill the contract of
Storage_Pool'Class. I guess that Allocate is allowed to raise
Storage_Error, but not to ignore parameters.

If the implementation handles a family of pools one per object's size power
of two or like that, then it should return the family root rather than the
size-specific pool. Otherwise, the following will work either:

type Integer_Ptr is access Integer;
type Character_Ptr is access Character;
for Character_Ptr'Storage_Pool use Integer_Ptr'Storage_Pool;

I think ARM should clarify the issue of how pools could be constrained
while allowing a safe use.

> However, I see nothing wrong with having a predefined operation that
> returns a suitable pool.

Yes. 

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