Balon vernacular msdn: Exporting C ++ classes from common DLL (2)-a closer look at the underlying mechanism of exporting C ++ classes

 

Balon vernacular msdn: export C ++ classes from common DLL (2)-a closer look at the underlying mechanism of exporting C ++ classes in the previous article, we introduced how to export C ++ classes from a DLL and how to selectively export C ++ class members. So what is the underlying mechanism of the entire system? In what ways can we use the class exported from one DLL in another program? We know that to use a C ++ class, the necessary condition is that the header file of this class can be obtained during the compilation period, you can also find the link addresses of the corresponding symbols (such as member functions and static data members) during the link period ). If the C ++ class is in the same project as your user, this condition is well met: first, the header file of the C ++ class is well obtained. Directly include the Class header file from the user. The C ++ class is often used by the compiler as a compilation unit to generate an OBJ file. During the final link process, the linker will link all OBJ links in the project to generate the final binary target file. Therefore, when the linker encounters a class member function (or other forms of symbolic reference), it will find the symbolic link address in the OBJ file generated by this class. So what is the need to use a C ++ class in the Code during the compilation and link phases? In other words, the compiler and the linker will not complain about what conditions are met? According to the definition of C ++, a C ++ class declares or defines the following types of content: 1. declares a data structure, non-static data members in the class, virtual table entry address pointers that cannot be seen in the Code but will be generated if there is a virtual function. 2. Declare and define a bunch of functions. Their first parameters are a pointer to this data structure. These are actually non-static member functions (including virtual functions) in the class. Although they are written inside a pair of braces in the class declaration, however, nothing is actually added to the internal data structure described in the preceding 1st. In fact, such a declaration only adds two attributes to these functions: the scope of the function name identifier is limited to the class; the first parameter of the function is this, which is ignored. 3. Declare and define another bunch of functions. They seem to be some common functions and have almost no relationship with this class. These are actually static functions in the class. They are the same. They do not add anything to the internal data structure described in Article 1st, but the scope of the function name identifier is limited to the class. 4. Declare and define a bunch of global variables. These are actually static data members in the class. 5. Declare and define a global variable, which is a function pointer array used to save the entry addresses of all such virtual functions. Of course, the premise for generating this global variable is that this class has virtual functions. The following is an example. Class myclass
{
Public:
Int X;
Int y;
Void Foo ();
Void bar (INT newx, int newy );
Virtual void vfoo ();
Virtual void vbar (INT newx, int newy) = 0;
Static void sfoo ();
Static void sbar (INT newx, int newy );
Static int SX;
Static int sy;
};
For this class myclass listed above, most C ++ compilers compile in the following way: now let's take a look at why the compiler needs header files and symbolic addresses to compile a program that uses myclass. First, the compiler needs to know the memory layout of the class during the compilation period to ensure that the correct code for opening up the memory and the sizeof (myclass) values can be generated. With the header file, the compiler will know that a myclass occupies 12 bytes of memory (see two integers and a pointer ). Secondly, when calling member and static functions of myclass, the linker needs to know the entry address of these functions. If the entry address cannot be provided, the linker reports an error. Finally, when referencing static data members of myclass, the linker needs to know the addresses of these variables just like referencing an external global object. If the address of these variables cannot be provided, the linker also reports an error. It can be seen that: 1. compilation period: the Class header file must be provided so that the compiler can know the size and memory layout of the class instance. 2. Link period: You must provide the addresses of member functions, static functions, and static data members referenced in the program so that the linker can correctly generate the final program. Here, we can guess that, in fact, to export a class, the compiler actually only needs: member functions, static functions, and static data members can be exported as common functions and global variables. In other words, we do not actually "export a class", but export the endpoint address of the "defined entity" to be referenced in this class as normal functions and variables. Finally, let's take a look at the generated DLL for exporting the myclass class in the previous column. You can see the following result by using dependence: except that the vbar function is a pure virtual function, the entry addresses of other functions and static data members are exported. In addition, we can see that vtable is also exported for reference when operating virtual functions.

Balon vernacular msdn: export C ++ class (1)-How to Use dllexport and dllimport from common DLL (Chinese-English comparison and note solution) I am a little lazy when writing this content, this avoids a lot of complex contents in virtual tables. Thanks to houdy's prompt, he analyzed the underlying mechanism of virtual tables and exported virtual tables from DLL in detail in his article. To answer this question, you must take a look: where is the virtual function table?