Derelict SFML destructor crashes

[Mike Parker]

On Monday, 17 December 2012 at 12:08:29 UTC, Nekroze wrote:
>
> Structs have their destructors called, as far as i understand, 
> as soon as you go out of the scope they are defined in. Not 
> sure how that works with structs that are members of a class 
> but i assume that has the same problems as a class's destructor.

Structs are stack objects (unless you allocate them with new and 
get a pointer). Stack objects will always have their destructors 
called when their scope exits. It's the only time you can rely on 
a destructor.

What is the scope of a struct that is a member of a class? I 
haven't tested it (I generally don't use struct destructors) but 
I would guess that when the class destructor is run, any structs 
that are members are also destructed. But not before then.

The same cannot be said of class instances that are class 
members, because they are also GCed object. Given class A a,  
which has a member instance of class B b, once 'a' is no longer 
referenced by the program, it does not mean that 'b' is also no 
longer referenced. There could be another reference to it 
somewhere else. So its eventual destruction will be completely 
independent from that of 'a'. Which is why you should never do 
anything like this:

~this()
{
    destroy(b);
}

>
> Classes don't have this guarantee because when they go out of 
> scope, again as far as i understand, they are just added to the 
> gc list of things that may need to be cleared (presuming they 
> are not stored elsewhere still?) and are cleaned whenever the 
> GC feels like it.

Class instances are marked for deallocation when the GC 
determines that there are no more references to them. Every time 
you allocate more memory, the GC will decide if it needs to free 
up any previously allocated memory. Different GCs will use 
different algorithms for this, so there's no way to have any 
influence over which objects are deallocated when.

>
> Now what i was thinking as a solution, would it be possible to 
> manually run the GC cleanup pass at the end of main this way we 
> know that the GC cleanup would run before main exits and thus 
> sfml gets unloaded. Although i believe this still doesn't 
> guarantee that it will think the class is fit for 
> deconstruction at that point so it may still no work but just a 
> thought.

There's no reason to do that. If you have any external resources 
to cleanup, just clean it up yourself. The init/term pattern I 
posted earlier works just fine.