Author : Andrew Fenster
Page : 1 Next >>
This article was contributed by Andrew Fenster.
Environment: Visual C++
As I discussed in the last article, .DLLs are a useful tool for any MFC programmer. They are subject to a number of important limitations, however, and anyone who is making .DLLs should be aware of these.
MFC Issues
This was discussed in the last article, but is worth mentioning again briefly. An MFC extension .DLL can only be used if the client application dynamically links to the same version of MFC, and the correct MFC code library .DLL is available on the client computer. A regular .DLL which dynamically links to MFC will only work if the correct MFC code library .DLL is available.
Compiler Incompatibility Issues
One of the biggest problems with C++ based .DLLs arises when a .DLL is built on one brand of compiler and called by an application built on another brand of compiler. Often it won't work without a great deal of effort.
ANSI sets the standards for the C and C++ languages. That is, it specifies the C and C++ functions and data types which should be supported by a compiler. It does not, however, provide a complete standard as to how these functions and data types should be implemented on a binary level. As a result, compiler vendors are free to implement language features in their own proprietary ways.
Most C / C++ programmers know that different compilers handle data types differently. One compiler will allocate 2 bytes for an int and another will allocate 4 bytes. One will use 4 byte doubles and another will use 8 bytes. An even bigger difference with C++ compilers arises from their implementation of function and operator overloading. The differences between compilers go far beyond this, however. The same C or C++ code may be compiled very differently by different compilers. These differences may keep your .DLL from running with someone else's application.
Of course, if you are building an MFC extension .DLL, this is not an issue for you. MFC extension .DLLs are made with a Microsoft compiler. As discussed in the previous article, they can only be used by applications that are dynamically linked to MFC. These applications are also made with a Microsoft compiler.
Compiler incompatibility problems can be fixed by inserting pragmas and other precompile instructions into your code, but this is hard to do and unreliable. There will always be the chance that someone else is using a compiler that's still incompatible.
Recompiling
Let's say you built a .DLL that exports a class called CMyClass. You provide a copy of the header file for CMyClass to be used by the client application. Suppose that a CMyClass object is 30 bytes in size.
Now let's suppose you modify the .DLL to change CMyClass. It still has the same public functions and member variables, but now CMyClass has an additional private member variable, an int. So now, when you create an object of type CMyClass, it's 34 bytes in size. You send this new .DLL to your users and tell them to replace the old .DLL. Now you have a problem. The client application is expecting a 30 byte object, but your new .DLL is creating a 34 byte object. The client application is going to get an error.
Here's a similar problem. Suppose that instead of exporting CMyClass your .DLL exports several functions which use CMyClass references or pointers in their parameters or return values. You have provided a CMyClass header file which now resides in the client application. Again, if you change the size of the CMyClass object without rebuilding the client application, you will have problems.
At this point, the only way to fix the problem is to replace the CMyClass header file in the client application and recompile it. Once recompiled, the client application will start looking for a 34 byte object.
This is a serious problem. One of the goals of having a .DLL is to be able to modify and replace the .DLL without modifying the client application. However, if your .DLL is exporting classes or class objects, this may not be possible. You may have to recompile the client application. If you don't have the source code for the client application, you simply can't use the new .DLL.
Solutions
If there were a perfect fix for these problems, we might not have COM. Here are a few suggestions:
MFC extension .DLLs don't have compiler incompatibility problems. They simply can't be used by applications built on non-Microsoft compilers. As for regular .DLLs, you can avoid many compiler problems by only exporting C-style functions and using the extern "C" specifier. Exporting C++ classes and overloaded C++ functions leaves you much more vulnerable to compiler incompatibility.
As for having to recompile your client application when you modify the .DLL, there are relatively easy ways to avoid the problem. I will describe two of them: (1) an interface class and (2) static functions used to create and destroy your exported class.
Using an Interface Class
The goal of an interface class is to separate the class you want to export and the interface to that class. The way to do this is to create a second class which will serve as the interface for the class you want to export. Then, even when the export class changes, you will not need to recompile the client application, because the interface class remains the same.
Here's an example of how that would work. Suppose you want to export CMyClass. CMyClass has two public functions, int FunctionA(int) and int FunctionB(int). If I simply export CMyClass, I'll have to recompile the client application every time I add a new variable. Instead, I'll create and export an interface class, CMyInterface. CMyInterface will have a pointer to a CMyClass object. Here's the header file for CMyInterface as it looks inside the .DLL:
#include "MyClass.h"
class __declspec(dllexport) CMyInterface
{
//private pointer to CMyClass object
CMyClass *m_pMyClass;
CMyInterface( );
~CMyInterface( );
public:
int FunctionA(int);
int FunctionB(int);
};
Inside the client application, the header file will look slightly different. The #include will be gone. After all, you can't include MyClass.h, because the client application doesn't have a copy of it. Instead, you will use a forward declaration of CMyClass. This will allow you to compile even without the CMyClass header file:
class __declspec(dllimport) CMyInterface
{
//Forward declaration of CMyClass
class CMyClass;
CMyClass *m_pMyClass;
CMyInterface( );
~CMyInterface( );
public:
int FunctionA(int);
int FunctionB(int);
};
Inside the .DLL, you implement CMyInterface as follows:
CMyInterface::CMyInterface( )
{
m_pMyClass = new CMyClass;
}
CMyInterface::~CMyInterface( )
{
delete m_pMyClass;
}
int CMyInterface::FunctionA( )
{
return m_pMyClass->FunctionA( );
}
int CMyInterface::FunctionB( )
{
return m_pMyClass->FunctionB( );
}
Thus, for every public function in CMyClass, CMyInterface will provide its own corresponding function. The client application has no contact with CMyClass. If it wants to call CMyClass::FunctionA, it instead calls CMyInterface::FunctionA. The interface class then uses its pointer to call CMyClass. With this arrangement, you're free to modify with CMyClass. It doesn't matter if the size of the CMyClass object changes. The size of the CMyInterface object will remain the same. If you add a private member variable to CMyClass, the size of CMyInterface will remain unchanged. If you add a public member variable to CMyClass, you can add "getter" and "setter" functions for the new variable in CMyInterface without fear. Adding new functions to CMyInterface will not cause recompile problems.
Creating a separate interface class avoids some compiler incompatibility problems and most recompile problems. As long as the interface class doesn't change, there should be no need to recompile. There are still two relatively minor problems with this solution. First, for every public function and member variable in CMyClass, you must create a corresponding function or variable in CMyInterface. In the example there are only two functions, so that's easy. If CMyClass had hundreds of functions and variables, this would be a more tedious, error-prone process. Second, you are increasing the amount of processing that must be done. The client application no longer calls CMyClass directly. Instead, it calls a CMyInterface function which calls CMyClass. If this is a function that will be called thousands of times by the client application, the extra processing time may begin to add up.
Static Functions
A different way to avoid having to recompile uses static functions to create and destroy the exported class. This solution was sent to me by Ran Wainstain in
Page : 1 Next >>