== Quote from Peter Alexander ([email protected])'s article > On 26/09/11 7:46 PM, dsimcha wrote: > > == Quote from Peter Alexander ([email protected])'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.
