GC for noobs

[Szymon Gatner]

On Thursday, 27 February 2014 at 12:32:36 UTC, Namespace wrote:
> On Thursday, 27 February 2014 at 12:25:49 UTC, Szymon Gatner 
> wrote:
>> On Thursday, 27 February 2014 at 11:13:17 UTC, bearophile 
>> wrote:
>>> Szymon Gatner:
>>>
>>>>I just want them to do their cleanup first as they should.
>>>
>>> Why? Perhaps if you explain what's behind your needs better, 
>>> people can help better.
>>>
>>> Bye,
>>> bearophile
>>
>> In my specific example I am creating OpenGL Renderer. Renderer 
>> class instance holds GLContext instance. After context 
>> creation GL objects are created like textures and vertex 
>> buffers. Those are Texture and VertexBuffer class instances 
>> too. It is critical that those child resources are freed 
>> before GL context is destroyed. Thing is, even tho Renderer 
>> keeps list of Textures , VertexBuffers and  Context object, 
>> order of their destruction is completely undefined making 
>> Context d-tor called first and then child resources d-tors 
>> which ends in catastrophe.
>>
>> In C++ (which has a LOT of problems) this is a no-brainer. 
>> Order of d-tors is fully defined. Sub-objects are destroyed 
>> before parent d-tor is called so only thing to worry about is 
>> the order of definition of members.
>>
>> This is just an example but I would think that it is something 
>> rather important to have... What about child objects 
>> un-registering themselves in d-tors from a list that parent 
>> object holds and parent is destroyed first? What about 
>> asynchronous completion handler object that should notify some 
>> other object that it finished/not finished a job but a notifee 
>> is already destroyed because application is being shut-down? I 
>> honestly can't imagine how to reason about object graph 
>> lifetimes in GC world and I am sure I am missing something 
>> very basic. Probably a very different mindset.
>
> I had the same problem in Dgame. Therefore I use shared 
> pointers 
> (https://github.com/Dgame/Dgame/blob/master/Graphics/Surface.d#L90) 
> or if I have to use classes, I use this:
>
> https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L44
> https://github.com/Dgame/Dgame/blob/master/Window/Window.d#L177
>
> I put the instances in a module global array and the module 
> dtor finalize the data.

Module d-tor() looks like a pretty good solution, thanks. 
shared_ptr tho... I was really hoping that I am moving away from 
it to a better place...

Still, this feels like working around a language issue, if c-tor 
order is defined why d-tor isn't? I am ok with non-deterministic 
time of execution of d-tors/finalizers but not-having 
parent-child d-tor order defined? That is weird.