Sign in to follow this  

Problem with interoperability of DLLs

This topic is 4686 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
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

This topic is 4686 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this