Jump to content
  • Advertisement
Sign in to follow this  
GD-Silver

Problem with interoperability of DLLs

This topic is 5024 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm having a problem with a couple of libraries that I'm designing, and it seems to be related to inoperability between DLLs. I am designing a GUI library for DirectX in C++, and I have three separate DLLs, one for graphics, one for input, and one for GUI controls. The input and control libraries both use the graphics library to handle drawing. The problem I've having is this: The graphics library contains a class called PictureSet, which is basically a wrapper around a DirectX texture. The other libraries use this class, and they don't seems to have a problem unless the objects are created using the "new" keyword and deleted using "delete". What's happening is that I am storing several of these objects in a hash_map that is the central holding place for graphics, and when the program terminates, the program iterates over all members of the hash_map and deletes them. The destructor of the PictureSet then tries to release its IDirect3DTexture9 object. When it tries to do this, however, the program throws an exception. Digging through Microsoft's code, it seems to indicate that the problem stems from the fact that I am trying to delete from a non-local heap. I am kind of new with DLLs, so can someone help me understand exactly what is going on here and how I can fix it? Thanks,

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Memory allocated in a Dll needs to be released in the same Dll.

Share this post


Link to post
Share on other sites
The AP is right. One simple way to share classes is to have something like this:


class MyClass
{
private:

MyClass(void);
~MyClass(void);

public:

static MyClass* Create(void);
virtual void Release(void);
};

MyClass* MyClass::Create(void)
{
return new MyClass();
}

void MyClass::Release(void)
{
delete this;
}


Now, the only way to delete an object of type 'MyClass' is to call Release() on it. The Release() method is virtual so that the function will be executed by the same instance that created it (eg. either the application or the DLL).

Share this post


Link to post
Share on other sites
If that's true, why do I not encounter the same problem with statically-allocated objects of this type? Doesn't the same principle apply?

Share this post


Link to post
Share on other sites
The problem is not with the object itself, but because of the dynamic allocation. The application and the DLL both use different dynamic allocation heaps.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!