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