On 5/19/15 5:07 PM, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonym...@anonymous.com> wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
<destructiona...@gmail.com> wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the same
time and may clean up the class and its members in any order.
Ugh... I was really hoping D had something better up it's sleeve.
It actually does, check out RefCounted!T and Unique!T in std.typecons.
They're sort of limited right now but undergoing a major revamp in 2.068.
Any idea what the plans are?. Does RefCounted become thread safe?
Correct me if I'm wrong though, but even if RefCounted itself was
thread-safe, RefCounted objects could still be placed in classes, at
which point you might as well use a GC'ed class instead, because you'd
be back to square-one with your destructor racing around on some random
thread.
With the current GC, yes. RefCounted needs to be thread safe in order to
use it. But if we change the GC, we could ensure destructors are only
called in the thread they were created in (simply defer destructors
until the next GC call in that thread).
I'm finding it hard to be optimistic about the memory model of D.
The idea of marking absolutely everything in your program with "@nogc"
just to make it safe is ludicrous.
That makes no sense, the GC is not unsafe.
-Steve