On 26/09/11 8:25 PM, dsimcha wrote:
== Quote from Peter Alexander (peter.alexander...@gmail.com)'s article
On 26/09/11 7:46 PM, dsimcha wrote:
== Quote from Peter Alexander (peter.alexander...@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.
