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.
