Re: Custom Storage Pool questions

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

"Jere" <jhb.chat@gmail.com> wrote in message 
news:036086ba-ea40-44cb-beb7-cded0f501cfbn@googlegroups.com...
> On Monday, September 13, 2021 at 1:29:39 AM UTC-4, Randy Brukardt wrote:
>> Not sure what you are expecting. There is no requirement that objects are
>> allocated contigiously. Indeed, Janus/Ada will call Allocate as many 
>> times
>> as needed for each object; for instance, unconstrained arrays are in two
>> parts (descriptor and data area).
>>
> No expectations.  Just questions.  I wasn't concerned with whether the
> allocated memory was contiguous or not, but whether an implementation
> is required to supply the correct size of memory needed to allocate an 
> object
> or if it is allowed to pass a value to Size that is less than the amount 
> of
> memory actually needed.  For example, the blog there indicates the
> maintainer of the custom storage pool needs to account for First/Last
> indexes of an unconstrained array separately instead of assuming that 
> value is
> included as part of the Size parameter's value.
>
> If the Size parameter doesn't require that it includes space for 
> First/Last
> for unconstrained arrays or Prev/Next for controlled objects (assuming
> that is even the implementation picked of course), then I'm not seeing
> a way to write a custom storage pool that is portable because you need
> to account for each implementation's "hidden" values that are not 
> represented
> in the Size parameter.

No, that would be wrong. The implementation has to calculate the Size of 
memory that it needs, no less.

>  For example if Janus calculated Size to have
> both the size of the array and the size of First and Last but GNAT didn't
> and my storage pool assumed the JANUS method, then if someone
> used my storage pool with GNAT then it would access memory
> from some other location potentially and erroneously.

No. What you cannot assume is that all of the memory is allocated at once. 
There can be multiple parts. But the compiler has to figure out the right 
size for each part, it can't tell you it needs 8 bytes and use 10. That 
would be a broken compiler.

>> The only thing that you can assume in a portable library is that you get
>> called the same number of times and sizes/alignment for Allocate and
>> Deallocate; there's no assumptions about size or alignment that you can
>> make.
> So to be clear, you cannot assume that Size and Alignment are appropriate
> for the actual object being allocated correct?  Size could actually be
> less than the actual amount of memory needed and the alignment may only
> apply to part of the object being allocated, not the full object?

Yes and no. You can't assume anything about the Size and Alignment passed. 
But whatever is passed has to be what the compiler actually needs.

> Is that correct?  I'm asking because that is what the blog suggests with
> the example it gave.

The blog sounds like nonsense for most uses. It sounds like someone is 
trying to do something very GNAT-specific -- and that's fine (I have lots of 
pools that assume the size of array descriptors in Janus/Ada to separate 
those from the array data allocations). But it's irrelevant for normal use.

>>
>> If you want to build a pool around some specific allocated size, then if 
>> it
>> needs to be portable, (A) you have to calculate the allocated size, and 
>> (B)
>> you have to have a mechanism for what to do if some other size is 
>> requested.
>> (Allocate a whole block for smaller sizes, fall back to built-in heap for
>> too large is what I usually do).
>>
> Are there any good tricks to handle this?  For example, if I design a
> storage pool around constructing a particular type of object, what is
> normally done to discourage another programmer from using the pool with
> an entirely different type?  Maybe raise an exception if the size isn't 
> exact?
> I'm not sure what else, unless maybe there is an Aspect/Attribute that
> can be set to ensure only a specific type of object can be constructed.

I either raise Program_Error (if I'm lazy), or simply hand off "wrong-sized" 
allocations/deallocations to the standard Storage_Pool.

                             Randy.