problem with freeing memory in dll

[Paul McKenzie]

one method that works is as zaccheus said using another external function in the dll to delete the object.

I stated the same thing back in post #9, but for some reason, you just glossed over it.

In general, the only memory allocation functions that work across compilers are the OS memory allocation functions. In Windows, you have GlobalAlloc(), HeapAlloc(), etc. These set of functions are guaranteed to be compatible across compilers, and even across different computer languages that have access to the Windows API functions.

As far as Borland goes, I have a DLL written in Visual C++, and Borland compilers use it with no problems whatsoever. The DLL does as I stated -- it allocates and deallocates its own memory when it comes to "new" and "delete". In addition, any memory that the DLL wants to give to the app to handle for themselves, that memory is obtained using the OS functions, as mentioned previously.

secondly, and this actually fixed my original
problem with LoadLibrary/FreeLibrary. I was looking at the documentation for FreeLibrary and it says when it is called it will call DllMain. i didn't previously have that

That shouldn't make any difference. If your DLL does not have a DllMain, then one is automatically added that does the default (return TRUE). So I don't know if you really fixed anything or your compiler is seriously broken in terms of producing valid DLL's.

Regards,

Paul McKenzie

[Zaccheus]

here's a link to a site i had found about exporting classes from a dll.
http://www.codeproject.com/KB/cpp/ho...p_classes.aspx

That's a great article!

[rhboarder]

sorry paul, i mustn't have seen that post. i thought the same thing that it shouldn't make a difference, so maybe it is my compiler.

[Glensmi]

For your CreateObject to work correctly all class methods that you wish to use in the exe that are defined in the parent have to be virtual. This also includes the destructor. The reason for this is that the object returned via Createobject has a virtual function table which will give you access to the methods without a GetProcAddress

[Zaccheus]

A destructor only needs to be virtual if you want to call delete on a base class pointer.

[Glensmi]

For the release to be implemented in the dll it would be doing a delete on the base class.

[Zaccheus]

Nope, release is always implemented in the most derived class.