Library file generation, including Static library lib and dynamic library DLL, need to change the compilation output of the build command , you can start to generate the corresponding library project (or in the project properties, general, Configuration type changes).
Basic corresponding commands are attached:
Gcc–c-l |
. o |
CL/C/link |
. obj |
ar |
.a |
lib |
.lib |
Ld |
. o |
Link |
. dll |
Where the dynamic library DLL needs to add the _declspec (dllexport) declaration before the output object.
For library use , in addition to including the corresponding header file, the static library needs to add #prama comment (lib, "Cof.lib") in the file.
or in the following situations:
1) Under the same solution, you can add a static library project in the Properties panel "frame and reference" and add the include file to "C + +"
2) Add the library's directory to the "link" 's Additional dependencies, and use Add cof.lib (same as pragma) in "input"
There are two ways to use Windows dynamic libraries, using LIB to import libraries, and using the window API
1) The Lib import library is used in the same way as the static library, but the "object" in the header file should have the _declspec (dllimport) Declaration
2) window API does not require header files
Export class:
1 Simple examples
DllExample.h:
#pragma once #ifdef Dll_exports #define DLL_API __declspec (dllexport) #else #define DLL_API __declspec (dllimport) #endif extern Dll_api int A; Class Dll_api Exportclass { Pirvate: int x; Public void foo (); }; |
DllExample.cpp:
#define Dll_exports #include "dllExample.h" int a = 4; void Exportclass::foo () { //do something ... return; } |
However, there is a limit to this simple DLL export if we export a class that contains a non-C + + base type:
DllExample.h:
#pragma once #ifdef Dll_exports #define DLL_API __declspec (dllexport) #else #define DLL_API __declspec (dllimport) #endif Class Dll_api Exportclass { Pirvate: std::string x;// the string type export here is not secure Public void foo (); }; |
We know that for STL, Microsoft has different implementations for each version of VS, VS2008 (VC90), VS2010 (VC100), VS2013 (VC120).
Due to the different implementations of STL, we can not see the direct transfer of std::string in different versions, otherwise unpredictable errors may occur during the run time.
In fact, the std::string x variable in our exportclass is not expected to be used externally, that is, there is no need to export, in fact, it is not recommended to let the DLL out of any definition of non-C + + base type.
But because Exportclass needs to be exported outward (because of the need to use the Foo () function), how should we deal with such contradictions?
For such a problem, we need to use the abstract class of C + + (which is actually the interface concept in Java) to solve:
We need to:
1. Declare a base class that has only pure virtual functions and C + + base types, and all definitions that need to be exported externally are included in the class.
2. Declare another class, inheriting the base class.
3. Implement a getinstance function that returns a pointer to a base class function, that is, a factory method that returns an instance of a derived class.
4. In external code, the class is accessed through a polymorphic mechanism.
DllExample.h:
#pragma once #ifdef Dll_exports #define DLL_API __declspec (dllexport) #else #define DLL_API __declspec (dllimport) #endif Class Dll_api Exportinterface { Public virtual void foo () = 0; }; extern "C" Dll_api exportinterface* getinstance (); #ifdef dll_exports // We do not need to export the definition of the class, nor do we need to include the definition of the class when the external code is compiled. Class Exportclass:public Exportinterface { Pirvate: std::string x;// the std::string is safe here because external code is not visible to this . Public void foo ();// function body implemented in dllExample.cpp }; #endif |
DllExample.cpp:
#define Dll_exports #include "dllExample.h" extern "C" Dll_api exportinterface* getinstance () { exportinterface* pinstance = new Exportclass (); return pinstance; } void Exportclass::foo () { //do something ... return; } |
calling convention
About nesting of multiple libraries:
§ Static library contains: Static library or dynamic library
Only the references to other libraries are declared as extern, and the Lib file of the library does not contain the specific implementations of other libraries, mainly in the final link application.
§ Dynamic Library contains: static, dynamic library
In its own place should contain the static library lib, the dynamic library of the import library lib, and then in the final call to the dynamic library of the place only need to introduce the import of this library. However, the final implementation should have a corresponding dynamic library.
Windows Build Library files