Johannes Pfau wrote:
>Sean Eskapp wrote:
>>I'm having an unfortunate DSFML issue, where failing to free objects like Images or Sprites causes exceptions to eventually be thrown. Calling the built-in member dispose() causes access violations, so I assume it's not for programmer use.
>>
>>However, I need the resources to be freed more quickly than the GC is apparently doing (I assume the Images and Sprites are eventually cleaned up), so is there a way to invoke a GC cleanup in some way?
>
>I don't think that invoking the garbage collector is a good solution in
>this case. "dispose" is indeed defined as "protected", so you probably
>should not call it manually, but then there really should be a public
>dispose like function. The reason for the crashes when calling
>dispose manually is simple: dispose calls a c sfml function to release
>c resources. The destructor calls dispose again, dispose tries to free
>an invalid pointer -> crash. So what should probably be done is to
>define a private m_disposed member and only call dispose if it hasn't
>been called before. Try to add this code to the DSFMLObject class in
>dsfml/system/common.d:
>
>-------------------------------------
>private:
>    bool m_disposed = false;
>
>public:
>    final void releaseRessources() //Needs a better name, though
>    {
>        if(m_disposed || m_preventDelete)
>            return;
>        dispose();
>        m_disposed = true;
>    }
>-------------------------------------
>
>And change dispose() in the DSFmLObject ~this() to releaseRessources();
>
>(Crashes might still occur if dispose is called directly. In the end,
>this might need a little more thinking, but that's up to the DSFML
>authors ;-))

The releaseRessources function should also check for m_preventDelete. Updated in the quote above.
-- 
Johannes Pfau