Goodbye, garbage collector!

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Wed Sep 28 03:18:43 PDT 2011


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 <b.helyer at gmail.com> 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.
>


More information about the Digitalmars-d mailing list