MFC. dll Guide (2 )-

The result of our discussion in the previous section is that DLLs is a very practical tool for any programmer. However, there are many restrictions on the use of DLLs. Anyone should be aware of this when working.

MFC issues
This has been mentioned in the previous section, but it is of great value. MFC extension. dll can be used only when the same MFC and correct MFC code library are used as the client program. regular. the same is true for DLL.

Compiler incompatibility issues
A very important issue is C ++-based. DLLs, when they are built on a compiler, but the client that calls them is built on another compiler, it usually does not work after much effort. :(
ANSI has developed standards for C and C ++ languages. that is to say, it specifies the C and C ++ functions and data types must be supported by a compiler. however, it does not provide a complete Binary-level implementation of functions and data types. as a result, the compiler vendor freely implements its language functions in its own way.
Many C/C ++ programmers know that the data types of different compiler operations are different. one compiler allocates 2 bytes for int variables, but the other may allocate 4 bytes. one will use a 4 bytes double, and the other may use an 8 bytes. there is a bigger difference between function implementation and operator overloading. different compilers have more differences than you think, so these differences make your. DLL cannot run on some programs.
The incompatibility problem of the compiler can be solved by inserting pragmas and other re-compilation instructions into your code, but it is difficult and hard to read. however, using incompatible compilers is unavoidable. the best way to solve compiler incompatibility problems is to let you. DLL exports a simple interface class so that it refers back to your. DLL, which will be discussed below.

Recompiling
Let's assume that you have created a class named cmyclass. DLL. when a client program connects to your. DLL ,. DLL creates an instance of this class and exports the instance. assume that your export instance is 30 bytes.
Now, if you have made some changes to cmyclass and added an int variable, the instance of your exported cmyclass will be changed from 30 bytes to 34 bytes, you will. DLL to the user to replace the original. now, the error is coming. The client program expects a 30-byte instance, but your new one. the DLL sends a 34-byte instance, and the client program throws an exception.
The client program does not need to change the code. All you need to do is import an instance of the cmyclass class. Add this line somewhere in the Code:

_ Declspec (dllimport) cmyclass myobject;

The client program code does not need to be changed. You only need to re-compile the client program to solve this problem. After re-compilation, the client program will wait for a 34-byte instance.
This is a very serious problem. It is only changing without re-compiling the client. DLL. DLL resetting is our goal. however, your. to export the entire class or an instance of a class, this goal is impossible. you must recompile the client. if you do not have the source code of the client, you will not be able to use the new one. DLL.

Solutions
If there is a good solution to the above problem, we will not use Com. Here are some suggestions:
Try to use the extended. DLLs of MFC. Although this limits the type of your client program, it solves the problem of compiler incompatibility.
If your. DLL export class or class instance, You have to modify it. DLL and then recompile your client. to avoid this, you must break down the class you want to export and implement an interface for the export class. the best way is to create a class that acts as the first class interface, so that if you change the export class, the interface class remains unchanged, and the client program does not need to be re-compiled.
Here is an example. suppose you want to export the cmyclass class. cmyclass has two public functions: int functiona (INT) and INT functionb (INT ). instead of exporting cmyclass, I will create an export interface cmyinterface. cmyinterface will contain an instance pointing to cmyclass. the header file is provided here:

Class afx_ext_class cmyinterface
{
Class cmyclass; // Forward Declaration of cmyclass
Cmyclass * m_pmyclass;

Public:
Cmyinterface ();
~ Cmyinterface ();

Int functiona (INT );
Int functionb (INT );
};

This header file will be used in. dll and client programs. Note that the previous statement means that compilation can be performed without cmyclass backup.
In. dll, implement cmyinterface as follows:

Cmyinterface: cmyinterface ()
{
M_pmyclass = new cmyclass;
}

~ Cmyinterface ::~ Cmyinterface ()
{
Delete m_pmyclass;
}

Cmyinterface: functiona ()
{
Return m_pmyclass-> functiona ();
}

Cmyinterface: functionb ()
{
Return m_pmyclass-> functionb ();
}

Therefore, cmyinterface provides the corresponding functions for every function of cmyclass. the customer program will not be in contact with the customer program. to call cmyclass: functiona, you only need to call cmyinterface: functiona. the interface class uses a pointer to call cmyclass. with this layout, you can change the cmyclass ---- don't worry about changing the cmyclass size. the interface size of cmyinterface remains unchanged. even if you add a private variable to cmyclass, The cmyinterface size does not change. if you add a Public Member, add the "Getter" and "setter" functions corresponding to the new variables directly in cmyinterface. Don't worry, add a new function, the cmyinterface class size does not change.
Creating a separate interface can avoid incompatibility with the compiler and client re-compilation. as long as the interface class remains unchanged, no re-compilation is required. but there are still two minor issues: 1. For each public member variable of cmyclass, you must create the actual corresponding function or variable in cmyinterface. in this example, there are only two functions, so it is very simple. if cmyclass has thousands of functions and variables, this will become very difficult and prone to errors. 2. You will increase the overhead of the process. the customer program no longer directly accesses cmyclass. Instead, it accesses cmyclass by accessing cmyinterface. if a function is called thousands of times, the process will take a long time.