Re: Ada containers and custom allocators

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

On Wed, 09 Jan 2008 16:58:22 -0500, in comp.lang.ada you wrote:

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

But a loose contract would make storage pools unusable. Actually it depends
on the semantics of the attribute P'Storage_Pool. When the result is a
constrained (optimized) pool then indeed there will be no way to fix it.

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

Either way is bad. Storage_Error should indicate a run-time problem, while
using an inappropriate pool is just a bug, basically a type error. And it
should be Constraint_Error then.

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

It is not wrong. Wrong is when P'Storage_Pool returns a specific pool from
the family. It should return a possibly less efficient family root pool,
which has to be present (when used). If an access type is created with this
root pool, the implementation is free to choose a more specific pool
instead. If for example the object size is known to be static. But that is
an implementation detail which may not leak outside (through
P'Storage_Pool, for instance). I think it should be no problem to remove
the root pool altogether upon linking when it is never used, i.e. there
should be no any overhead.

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