On Sunday, 16 December 2012 at 17:14:55 UTC, Maxim Fomin wrote:
On Sunday, 16 December 2012 at 15:21:46 UTC, Nekroze wrote:
On Sunday, 16 December 2012 at 14:59:32 UTC, Maxim Fomin wrote:
On Sunday, 16 December 2012 at 14:42:57 UTC, Nekroze wrote:
I am trying to do some wrapping of the CSFML derelict bindings to classes however when i use the CSFML methods to destroy the objects it causes a crash.

I have made a post in the SFML>D forum because they have syntax highlighting for D so this kind of post looks nicer but the link is here:

http://en.sfml-dev.org/forums/index.php?topic=10005.0

There is a minimal code example there and a better explanation.

Can anyone help me with why this is happening?

Why would you call a destroy() on a this object inside ~this()? And accessing allocated by GC objects inside destructor is not safe, because they may be collected before running the destructor.

I am sorry if i am being dim but i thought that the sfml objects are not GC objects so it will exist forever until i call its destroy function so why cant this be done in the destructor? Unless you mean the pointer is being destroyed before the destructor is being called?

I do not know this library, but if you get InvalidMemoryOperationError it likely mean that you call in class dtor some function, which causes GC allocation. In your case it seems that you call sfImage_destroy(image) which might do such things.

sfImage_destroy is purely a binding to a c function in a dll. It has no knowledge of the GC or anything which is why the image will live forever unless i call that function.

SFML is a c++ OO based graphics library, in order to provide a c binding they made a C wrapper around all the OO stuff so the object, its all handled using C functions, needs to have its destructor called manually with the C destroy functions. With the D wrapper for this (Derelict3) there is no actual function for these its just some kind of pass through binding to the dll so the above, as far as i can understand, still holds true.

This is why i have come to the belief that i should be perfectly able to call this destroy function in the destructor because what i am calling destroy on is an object that is created in C++ but accessed through C functions which have just been imported and bound to D names.

Reply via email to