On 04/25/2011 10:06 AM, Iain Buclaw wrote:
I was thinking of where one implements an alternative runtime that may not
necessarily interface with a GC, or has different semantics on the use of the
keyword (the compiler, after all, doesn't know/care what exactly 'delete' does,
it
just does it's job at emitting the correct action we expect from it). Though it
was late night and I perhaps didn't quite put it right anyway.
Having literally slept on it though, a runtime with a good GC is one that
doesn't
offer a choice to 'delete' memory - so I am on your side. Though reflecting
from
my experience with the D2 GC (thinking from a compiler implementers POV), there
isn't much I can really praise about it.
Custom (de)allocators I can also see a very good point for removal too, however
much a stab in the back for those who can use them in the - perhaps
'one-and-only'
- case for a small amount of speed gain.
Iain
I understand. The right response to this is defining a good custom
allocator API and providing good implementations of it.
Andrei
