C/c ++ create a dynamic link library

C/c ++ create a dynamic link library
Extern "C" C ++ retains the features of some procedural languages, so it can define global variables and functions that do not belong to any class. However, C ++ is an object-oriented programming language after all. To support function overloading, C ++ treats global functions differently from C.
The main function of extern "C" is to call other C code correctly. After extern "C" is added, it indicates that the code of the compiler is compiled in C language instead of C ++. C ++ supports function overloading. Therefore, during function compilation, the parameter types of the function are added to the compiled code, not just the function name; C language does not support function overloading. Therefore, when compiling a function in C language code, the parameter type of the function is not included. Generally, the function name is included.
For example, if you have developed a DLL library using C, in order to enable the C ++ language to call your DLL output (Export) function, you need to use extern "C" to force the compiler not to modify your function name.
Standard header file format:

# Ifndef _ INCvxWorksh/* prevents this header file from being repeatedly referenced */# define _ INCvxWorksh # ifdef _ cplusplus/_ cplusplus is a custom macro extern "C "{// tell the compiler, this part of the code is compiled in the C language format, instead of C ++ # endif/***** some declaration or so *****/# ifdef _ cplusplus} # endif/* _ INCvxWorksh */

Extern "C" contains a double meaning, which can be obtained literally: first, the target is "extern", and second, the target is "C.
The function or variable specified by extern "C" is of the extern type;
1. extern keyword
Extern is a keyword in C/C ++ that indicates the range (visibility) of functions and global variables. This keyword tells the compiler, the declared functions and variables can be used in this module or other modules.
In general, the function and global variables referenced by this module to other modules are declared with the keyword extern in the module header file. For example, if Module B wants to reference the global variables and functions defined in module A, it only needs to include the header file of module. In this way, when Module B calls A function in module A, although Module B cannot find the function in the compilation phase, it does not report an error.Link stageFind this function from the target code generated by module.
The keyword corresponding to extern is static. The global variables and functions modified by it can only be used in this module. Therefore, a function or variable can only be used by this module and cannot be modified by extern "C.

2. Variables and functions modified by extern "C" are compiled and linked in C language.
First, let's take a look at how C-like functions are compiled in C ++.
As an object-oriented language, C ++ supports function overloading, while Procedural Language C does not. The name of the function in the symbol library after being compiled by C ++ is different from that in the C language. For example, assume that the prototype of a function is:
Void foo (int x, int y );
After the function is compiled by the C compiler, its name in the symbol library is _ foo, while the C ++ compiler generates names such as _ foo_int_int (different compilers may generate different names, but all adopt the same mechanism, and the new name is called "mangled name ").
A name such as _ foo_int_int contains the function name, number of function parameters, and type information. C ++ relies on this mechanism to implement function overloading.For example, in C ++, the void foo (int x, int y) and void foo (int x, float y) functions generate different symbols, the latter is _ foo_int_float.
Similarly, variables in C ++ support both local variables and class member variables and global variables. The class member variables of the program written by the user may have the same name as the global variables, which are distinguished. In essence, the compiler uses a unique name for the variables in the class when compiling, similar to the function processing. This name is different from the global variable name with the same name in the user program.

3. Examples
(1) connection method without the extern "C" Declaration
Suppose in C ++, the header file of module A is as follows:

// Module A header file moduleA. h # ifndef MODULE_A_H # define MODULE_A_Hint foo (int x, int y); # endif

// Reference this function in Module B: // Module B's implementation file moduleB. cpp # include "moduleA. h" foo (2, 3 );

In fact, in the connection phase, the linker will find symbols such as _ foo_int_int from the target file moduleA. obj generated by module!

(2) Compilation and link methods after the extern "C" statement is added
After the extern "C" statement is added, the header file of module A is changed:

// Module A header file moduleA. h # ifndef MODULE_A_H # define MODULE_A_Hextern "C" int foo (int x, int y); # endif

In Module B's implementation file, foo (2, 3) is still called. The result is:

<1> when A compiles and generates the foo target code, it does not perform special processing on its name. The C language is used;

<2> when the linker looks for the foo (2, 3) call for the target code of Module B, it looks for the unmodified symbol name _ foo.

If the function in module A declares that foo is of the extern "C" type, and Module B contains the extern int foo (int x, int y ), module B cannot find the function in module A, and vice versa.

The true purpose of the extern "C" statement isImplement mixed programming of C ++, C and other languages.

C ++ code calls the C language code and uses it in the header file of C ++

When C ++ references functions and variables in C language, it must be processed as follows when it contains the C Language header file (for example, cExample. h:

 

extern "C"{#include "cExample.h"}

 

In the header file of the C language, the external function can only be specified as the extern type. The C language does not support the extern "C" declaration. when the c file contains extern "C", a compilation syntax error occurs.

/* C header file: cExample. h */# ifndef C_EXAMPLE_H # define C_EXAMPLE_Hextern int add (int x, int y); // Note: write it as extern "C" int add (int, int ); alternatively, you can # endif/* C implementation file: cExample. c */# include "cExample. h "int add (int x, int y) {return x + y;} // c ++ implementation file, call add: cppFile. cppextern "C" {# include "cExample. h "// note: this is not correct. If the compilation fails, replace it with extern" C "int add (int, int); you can use} int main (int argc, char * argv []) {add (2, 3); return 0 ;}

When C references functions and variables in C ++, the header file of C ++ needs to add extern "C ", however, you cannot directly reference this header file that declares extern "C" in C. You should only declare the extern "C" function defined in C ++ as the extern type.

// C ++ header file cppExample. h # ifndef CPP_EXAMPLE_H # define CPP_EXAMPLE_Hextern "C" int add (int x, int y); # endif // C ++ implementation file cppExample. cpp # include "cppExample. h "int add (int x, int y) {return x + y;}/* C implementation file cFile. c/* compilation errors: # include "cExample. h "*/extern int add (int x, int y); int main (int argc, char * argv []) {add (2, 3); return 0 ;}

_ Declspec (dllexport) and _ declspec (dllimport)

_ Declspec (dllexport)

_ Declspec (dllexport) exports a function, which is called by a program other than her program.
Extern "C" indicates that the compiler uses the C language method to name the function.
When creating a DLL export function, because C ++ has a function overload, _ declspec (dllexport) function (int, int) will be decorate in the DLL. For example, decorate will become function_int_int by decorate, in addition, different compilers decorate different methods cause inconvenience when GetProcAddress is used to obtain the function address. When extern "C" is used, the preceding decorate will not occur because C has no function overload, however, the function modified by extern "C" does not have the ability to overload. It can be said that extern and extern "C" are not the same thing.

_ Declspec (dllimport)

I believe that anyone who writes a WIN32 program, once working on a DLL, knows the role of _ declspec (dllexport) to reduce the need to manually define which functions to export in the DEF file. Of course, if your DLL contains all C ++ classes, you cannot specify the export function in DEF. Instead, you can use _ declspec (dllexport) to export the class. However, the description of _ declspec (dllimport) in the msdn document is a bit strange. Let's take a look at what is said in MSDN:

You can compile the code correctly without using _ declspec (dllimport), but using _ declspec (dllimport) enables the compiler to generate better code. The compiler can generate better code because it can determine whether the function exists in the DLL, which allows the compiler to generate code that skips the indirect addressing level, these codes usually appear in function calls across DLL boundaries. However, you must use _ declspec (dllimport) to import the variables used in the DLL.

First, it seems that this section above means that you can use DLL export without using it, but the last sentence also says that _ declspec (dllimport) must be used) to import the variables used in the DLL. What does this mean ??

Let me try it out. Assume that you only export a simple class in DLL. Note that I suppose you have defined SIMPLEDLL_EXPORT IN THE PROJECT properties.
SimpleDLLClass. h

#ifdef SIMPLEDLL_EXPORT#define DLL_EXPORT __declspec(dllexport)#else#define DLL_EXPORT#endifclass DLL_EXPORT SimpleDLLClass{public:SimpleDLLClass();virtual ~SimpleDLLClass();virtual getValue() { return m_nValue;};private:int m_nValue;};

SimpleDLLClass. cpp

#include "SimpleDLLClass.h"SimpleDLLClass::SimpleDLLClass(){m_nValue=0;}SimpleDLLClass::~SimpleDLLClass(){}

Then you can use this DLL class to include SimpleDLLClass in your APP. h, your APP project does not need to define SIMPLEDLL_EXPORT. Therefore, DLL_EXPORT will not exist. At this time, you will not encounter problems in the APP. This corresponds to the definitions of _ declspec (dllimport) in MSDN. However, we have not encountered that variables cannot be used normally. Well, let's change SimpleDLLClass, change its m_nValue to static, and then add a line in the cpp file.

int SimpleDLLClass::m_nValue=0;

If you don't know why you want to add this line, go back and look at the basics of C ++. After the change, LINK your APP and check the result. The result is that LINK tells you that the m_nValue cannot be found. Why is there no such thing as clearly defined ?? It must be because I defined m_nValue as static. But if I must use the Design Pattern of Singleton, then this class must have a static member, and there is no LINK each time. Isn't that all done? If you have the Platform SDK, use the Depend program to check whether the m_nValue is exported in the DLL.
Go back and check out the last sentence I mentioned in MSDN. Let's change SimpleDLLClass. h to the following:

#ifdef SIMPLEDLL_EXPORT#define DLL_EXPORT __declspec(dllexport)#else#define DLL_EXPORT __declspec(dllimport)#endif

LINK again. Everything works normally. Originally, dllimport was used to better process static member variables in the class. If there is no static member variable, this _ declspec (dllimport) does not matter.