GC Destruction Order

[rsw0x via Digitalmars-d-learn]

On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
> On Tue, 19 May 2015 15:36:21 -0400, rsw0x 
> <anonymous at 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 
>>> <destructionator at 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.