Sign in to follow this  

Weird problem because of DLL limitation

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

When i was designing my library, it was being compiled as a static library and all was well and good, but after a painful process in making it compile as a DLL, i thought it was all over, until i looked through some of my code and realised i have a problem. Situation looks like this: Inside DLL [ class dllExport Pass { //blah blah }; ] Client using DLL [ class MyUberPass : public dllImport Pass { //blah blah }; void main() { MyUberPass* mup = new MyUberPass(); } ] Pass is a generic class meant to be derived further by anyone using the library, now obviously they wont be able to export their derived class into my DLL, so whats the big deal you might ask? It should be totally fine to derive from a base class with it's implementation in a DLL and new it in another DLL/exe. But the problem is that all Passes are added to a PassRegistry when newed, which includes the ones derived and newed outside the dll. The PassRegistry will delete all Passes during shutdown/closing of program. This would mean that something which is new-ed in an exe will be deleted by the PassRegistry which resides in the DLL. I could make it so that all Passes created have to be deleted by the user, but im trying to save the user of doing so.

Share this post


Link to post
Share on other sites
I don't know if it's the best solution, but how about this:



Inside DLL
[
class dllExport Pass
{
//blah blah
virtual void Dispose()=0;
};
]

Client using DLL
[
class MyUberPass : public dllImport Pass
{
//blah blah
virtual void Dispose(){delete this;}
};

void main()
{
MyUberPass* mup = new MyUberPass();
}
]




When the PassRegistry wants to destroy all passes, it calls the virtual function Dispose(which you don't have to export since it's virtual and the calling address will be resolved at run-time). The objects deletes itself, so both "new" and "delete" will be called from within the client.

Although the best and most general solution would be to create something like a class factory inside the DLL, maybe something like a dictionary which would register the name of the class, a function that creates an instance and a function that deletes it, so you can create and destroy objects from everywhere using the factory.

Share this post


Link to post
Share on other sites
You know something, i did exatcly the same thing about 10 minutes after posting here. By making the dispose() = 0;, all derived classes have to implement a
delete this;

I dont know if there is a better way to do this, but i think this solution is currently the only way i can do it without sacrificing convenience.

Share this post


Link to post
Share on other sites

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