Pass CObject derived class between DLL calls

[AlanCCC]

Hi,

I define a CObject derived class called CMyClass, as follows:

class CMyClass : public CObject
{
..
}

Then I define two DLLs, DLL1.dll and DLL2.dll

DLL1.dll contains an export function called CreateMyClass, as follows:

CMyClass *CreateMyClass()
{
CMyClass *pMyClass;

pMyClass = new CMyClass;

return pMyClass;
}

DLL2.dll contains an export function called UseMyClass, as follows:

void UseMyClass(CMyClass *pMyClass)
{
if (pMyClass != NULL)
{
// Statements to use pMyClass
}
}

Then I want to build a third MFC application called MyApp.exe that will contain the following statements:

CMyClass *pMyClass;

// Invoke CreateMyClass in DLL1.dll to create a new instance of CMyClass
pMyClass = CreateMyClass();

// Invoke UseMyClass to use pMyClass
UseMyClass(pMyClass);

For MyApp.exe, DLL1.dll and DLL2.dll, I want to statically link the MFC library. Is that possible? Also are there any special requirements or attention need to pay when create and build these three projects?

Thanks

[Paul McKenzie]

Also are there any special requirements or attention need to pay when create and build these three projects?

You are treading on dangerous ground when you start passing objects across DLL boundaries, whether it is CObject or any user-defined object.

1) What would happen if you build the DLL with different compile options than the application, causing the CObject to be internally different?

2) What if you build the DLL with one version of Visual C++, and then you build the application with another version of Visual C++? Again, the issue of the internals of the CObject having differences come into play.

The bottom line is that when you pass any type of C++ object from DLL to application, all applications and all DLL's must be built with the exact same compiler options, and must be built with the same version of the compiler.

In addition, you have heap management issues -- you have to make sure that the application and DLL's use the same heap manager by linking to the DLL version of the runtime library. If the object does internal C++ heap management (calls to new/delete/malloc/free), then you must make sure the object on both sides, DLL and application, use the same heap manageer.

The only types guaranteed to be consistent as parameters between application and DLL's are the Windows "simple" types and pointers to those types. For example, DWORD, BOOL, INT_PTR, LPCTSTR, etc. (I won't list all of them). Passing anything else, including C++ reference types, cannot work consistently without going through the steps I specified earlier.

Regards,

Paul McKenzie

[ovidiucucu]

To prevent any further painful headaches, if you have an MFC-based application which uses MFC-based DLLs, always choose:

• Use MFC in a Shared DLL for the executable application.
• MFC Extension DLL (using shared MFC DLL) for DLLs.