GC for noobs

[Namespace]

On Thursday, 27 February 2014 at 13:00:27 UTC, Szymon Gatner 
wrote:
> 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.

I use this solution especially because I have to finalize the 
data before I call SDL_Quit. And therefore I cannot trust the 
non-deterministic execution of the Dtor.