Vote on region allocator

[Peter Alexander]

On 26/09/11 8:25 PM, dsimcha wrote:
> == Quote from Peter Alexander (peter.alexander.au at gmail.com)'s article
>> On 26/09/11 7:46 PM, dsimcha wrote:
>>> == Quote from Peter Alexander (peter.alexander.au at gmail.com)'s article
>>>>> T newArray(T, I...)(I sizes);
>>>>>
>>>>> // Usage:
>>>>> auto foo = newArray!(uint[])(5);
>>>>>
>>>>> This would be marginally do-able but very ugly if RTTI were used.
>>>> Ok, now I'm really lost. Where do allocators come into that?
>>>
>>> I'm sorry.  To clarify:
>>>
>>> SomeAllocator alloc;
>>> auto foo = alloc.newArray!(uint[])(5);
>>>
>>> The only way to do this with dynamic allocators would be a final templated
>>> function wrapping a function that takes RTTI.  This would be marginally do-able
>>> but very ugly.
>> Why on Earth would an allocator have a newArray method?
>> Allocators allocate bytes, they don't construct objects. newArray should
>> take an allocator:
>> // Template version
>> T newArray(A, T, I...)(A allocator, I...);
>> // Dynamic version
>> T newArray(T, I...)(IAllocator allocator, I...);
>> newArray then requests:
>> allocator.allocate( /+ bytes +/, /+ align (optional) +/ );
>> And constructs the array in those bytes.
>
> This was previously discussed in the review.  The problem is that the allocator
> may have a use for the type information, e.g. setting GC flags, etc.

In that case it should just pass that information to the allocator as 
well. The interface should be minimal and only request the information 
that it needs, no more.