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
signature.asc
Description: PGP signature