I assume when the allocators come along, the flexibility of those constructs will increase, no? Also, wouldn't it be cleaner to allow reuse of the incredibly convenient syntax of built-in arrays and enable one to replace it's allocators? Some properties, maybe? Something like this:
----- int[] array; assert(is(array.allocator == DynamicAllocator)); // This equals to GCAllocator().dynamicAllocator(). array.allocator = RegionAllocator.dynamicAllocator(). ----- And the functions of the allcoators, that create arrays, using that allcoator would write the above statements. How about this? And how much the performance would drop if we introduced DynamicAllocators to do all the allocations? Is there any other solution you could suggest, that would allow using built-in array syntax? What about stack frames, that get moved to heap? On Wed, Sep 28, 2011 at 1:57 PM, Bernard Helyer <[email protected]> wrote: > Using Array!T in place of T[] would work, if you don't mind malloc/free. > Also, overriding new and delete (and delete itself) are going -- relying > on them is not advisable. Use emplace and clear, instead. >
