On Tuesday, 19 May 2015 at 21:07:52 UTC, 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.
I don't understand what you're asking here. If you hold a
RefCounted resource in a GC managed object, yes, it will be tied
to the GC object's lifetime.
With your avoidance of the GC, I feel like you were lied to by a
C++ programmer that reference counting is the way to do all
memory management, when in reality reference counting is dog slow
and destroys your cache locality(esp. without compiler support.)
Reference counting is meant to be used where you need absolute
control over a resource's lifetime(IMHO,) not as a general
purpose memory management tool.
Bye.
