Derelict SFML destructor crashes

[Nekroze]

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.