SFML community forums

Bindings - other languages => D => Topic started by: RobotGymnast on February 03, 2011, 03:08:50 am

Title: Exception-throwing in destruction
Post by: RobotGymnast on February 03, 2011, 03:08:50 am
Code: [Select]

module main;

import dsfml.graphics.all;
import dsfml.window.all;
import std.stdio;

class ImageWrapper
{
private Image image;

this()
{
image = new Image(200, 200, Color.WHITE);
}

~this()
{
image.dispose();
}
}

void main()
{
try
{
try
auto img = new ImageWrapper;
catch(Exception e)
writeln(e.msg);
}
catch(Error e)
writeln(e.msg);
}


I'm guessing this throws an exception because the libraries are unloaded at the end of main(), and destruction occurs by the garbage collector after. If that's the case, then does that mean any wrappers I create need to be structs? Or am I misdiagnosing?
Title: Exception-throwing in destruction
Post by: Laurent on February 03, 2011, 07:48:55 am
Looks like the same problem that I had for the .Net binding. Apparently the GC is running in a thread that is not the main thread, which still runs after the latter has ended.
To solve this, the binding has to instanciate a dummy sf::Context in the GC thread.
Title: Exception-throwing in destruction
Post by: RobotGymnast on February 03, 2011, 12:50:56 pm
Quote from: "Laurent"
Looks like the same problem that I had for the .Net binding. Apparently the GC is running in a thread that is not the main thread, which still runs after the latter has ended.
To solve this, the binding has to instanciate a dummy sf::Context in the GC thread.


I tried putting
Code: [Select]

auto context = new Context;


At the beginning of my thread, and it didn't like that one bit. What should I do?
Title: Exception-throwing in destruction
Post by: Laurent on February 03, 2011, 01:24:57 pm
Nothing, this has to be handled in the binding directly (if the problem is similar).
Title: Exception-throwing in destruction
Post by: RobotGymnast on February 03, 2011, 09:44:12 pm
Quote from: "Laurent"
Nothing, this has to be handled in the binding directly (if the problem is similar).


So, for now, my solution has to be to put all wrappers inside scoped-destruction objects (i.e. structs)?