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.
