forcing "@nogc" on class destructors

via Digitalmars-d digitalmars-d at puremagic.com
Wed Jan 21 00:45:23 PST 2015


On Wednesday, 21 January 2015 at 03:03:50 UTC, Steven 
Schveighoffer wrote:
> It's neither spurious, nor a race condition.

How can you say that a priori? If you are using a framework, then 
subclass a node (which cannot be made @nogc), then do explicit 
deallocation to speed it up, then do multi-threading to speed it 
up... then any spurious memory leak due to races can result in 
crashes after deployment with this GC scheme.

The sad thing is that an innocent rare memory leak with C++ style 
memory allocation is less critical than a memory leak picked up 
by the GC.

That's bad marketing vs the C++ community which are highly 
sceptical to using a GC in the first place.


More information about the Digitalmars-d mailing list