Re: Ada containers and custom allocators

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Wed, 09 Jan 2008 10:29:46 -0500, Robert A Duff wrote:
>> 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.

What's the contract of Storage_Pool'Class?  It is certainly not intended
that all pools must support all sizes and alignments -- that would
defeat the optimization purpose of pools.

>...I guess that Allocate is allowed to raise
> Storage_Error, but not to ignore parameters.

Well, if it ignores the size, or raises an exception when the size is
not 4, either way, it won't work when the size is not 4.  But I agree
that an exception is better.  I'd like to suppress that check, though,
if it's too slow.

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

What if there is no such root?  How about an implementation that creates
one pool for each static size that is used in the program, up to 100
bytes.  Any access type whose designated type's size is nonstatic,
or > 100, uses a separate pool that can handle any size, and does
not call those static-size pools.  Each static-size pool has the
size built in to its code.

Sounds like an efficient implementation.  When you say "new Integer",
there's no need to check the size at run time, because the compiler
knows it's 4.  Do you think this implementation is wrong?

>...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 don't think the RM requires the above to work properly.

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

Perhaps.

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

- Bob