C++ DLL导出类知识大全

时间 2019-11-06

标签 c++ dll 导出知识大全栏目 C&C++ 繁體版

原文原文链接

在公司使用C++ 作开发，公司的大拿搭了一个C++的跨平台开发框架。在C++开发领域我仍是个新手，有不少知识要学，好比Dll库的开发。html

参考了不少这方面的资料，对DLL有一个基本全面的了解。有一个问题让我有点困惑，普通的导入导出C++类的方式都是使用_declspec(dllexport) /_declspec(dllimport)来导入导出类，可是在公司的开发中咱们没有导入导出，而是定义了一些只有纯虚函数的抽象类，而后定义了一个工厂类，将这个工厂类注册到框架的服务中心中，使用时从服务中心拿到这个工厂类，就能够建立Dll中的其它类。对这种使用方式我不太理解，google+百度搜索了不少这方面的内容，不少blog讲到了这种使用方式，可是也没有讲清楚这样使用的原理，后来找到了一篇老外写的blog，讲得比较清楚。编程

使用只有纯虚函数的抽象类之因此不须要导出，是由于纯虚函数的虚表使然。下面是同老外的bkig中抽出来的一个示例。框架

纯虚函数类的定义以下：函数

[cpp] view plain copy

// The abstract interface for Xyz object.
// No extra specifiers required.
struct IXyz
{
virtual int Foo(int n) = 0;
virtual void Release() = 0;
};
// Factory function that creates instances of the Xyz object.
extern "C" XYZAPI IXyz* APIENTRY GetXyz();

使用dll的代码以下：post

[cpp] view plain copy

#include "XyzLibrary.h"
...
IXyz* pXyz = ::GetXyz();
if(pXyz)
{
pXyz->Foo(42);
pXyz->Release();
pXyz = NULL;
}

该示例中导出了一个方法来建立IXyz对象，可是并无导出IXyz对象，IXyz类中只有纯虚函数。这是如何实现的呢？我所知道的是，须要将Dll中的类导出，导出的符号将放到导出符号表中，在连接的时候根据这些符号来定位函数的地址，这个IXyz类没有声明导出，固然类中的函数就不回生成在导出符号表中，那么怎么定位到函数的地址呢？下面这张原文中的图给出了很清晰的解释：学习

图中的伪代码部分解释了函数的调用过程，是经过虚表来定位函数的。由于定义的是只有纯虚函数的抽象类，这样的类编译以后会有一个纯粹的虚表，能够经过这张纯粹的虚表来进行函数调用，因此经过这种方式来使用dll的第一步是应以只带纯虚函数的抽象类，或者说接口。
更多内容，参见下面：ui

1、导出类的简单方式google

这种方式是比较简单的，同时也是不建议采用的不合适方式。加密

只须要在导出类加上__declspec(dllexport)，就能够实现导出类。对象空间仍是在使用者的模块里，dll只提供类中的函数代码。不足的地方是：使用者须要知道整个类的实现，包括基类、类中成员对象，也就是说全部跟导出类相关的东西，使用者都要知道。经过Dependency Walker能够看到，这时候的dll导出的是跟类相关的函数：如构造函数、赋值操做符、析构函数、其它函数，这些都是使用者可能会用到的函数。url

这种导出类的方式，除了导出的东西太多、使用者对类的实现依赖太多以外，还有其它问题：必须保证使用同一种编译器。导出类的本质是导出类里的函数，由于语法上直接导出了类，没有对函数的调用方式、重命名进行设置，致使了产生的dll并不通用。

部分代码（DLL头文件）：

//2011.10.6//cswuyg//dll导出类，比较差劲的方法#pragma once#ifdef NAIVEAPPROACH_EXPORTS#define NAIVEAPPROACH_API __declspec(dllexport)#else#define NAIVEAPPROACH_API __declspec(dllimport)#endif//基类也必须导出，不然警告：class  NAIVEAPPROACH_API CBase{public:    void Test();private:    int m_j;};//也必须导出class NAIVEAPPROACH_API CDate{public:    void Test2();private:    int m_k;};class NAIVEAPPROACH_API CNaiveApproach : public CBase{public:    CNaiveApproach(int i = 0);    // TODO: add your methods here.    void Func();private:    int m_iwuyg;    CDate m_dobj;};

Demo代码见附件NaiveApproach部分。

2、导出类的较好方式

这种方式是比较合适的，跟com相似。

结构是这样的：导出类是一个派生类，派生自一个抽象类——都是纯虚函数。使用者须要知道这个抽象类的结构。DLL最少只须要提供一个用于获取类对象指针的接口。使用者跟DLL提供者共用一个抽象类的头文件，使用者依赖于DLL的东西不多，只须要知道抽象类的接口，以及获取对象指针的导出函数，对象内存空间的申请是在DLL模块中作的，释放也在DLL模块中完成,最后记得要调用释放对象的函数。

这种方式比较好，通用，产生的DLL没有特定环境限制。借助了C++类的虚函数。通常都是采用这种方式。除了对DLL导出类有好处外，采用接口跟实现分离，可使得工程的结构更清晰，使用者只须要知道接口，而不须要知道实现。

　　部分代码：

（1）DLL头文件：

//2011.10.6//cswuyg//dll导出类//dll跟其使用者共用的头文件#pragma  once#ifdef MATUREAPPROACH_EXPORTS#define MATUREAPPROACH_API __declspec(dllexport)#else#define MATUREAPPROACH_API __declspec(dllimport)#endifclass IExport{public:    virtual void Hi() = 0;    virtual void Test() = 0;    virtual void Release() = 0;};extern "C" MATUREAPPROACH_API IExport* _stdcall CreateExportObj();extern "C" MATUREAPPROACH_API void _stdcall DestroyExportObj(IExport* pExport);

（2）导出类头文件：

//2011.10.6//cswuyg//dll导出类// 实现类#pragma once#include "MatureApproach.h"class ExportImpl : public IExport{public:    virtual void Hi();    virtual void Test();    virtual void Release();    ~ExportImpl();private:};

Demo代码见附件MatureApproach部分。

3、总结

导出类是比较简单的，比较容易混淆的概念上一篇总结已经说完了。本质上来讲，跟导出函数没差异。使用VS2005自动生成的代码能够省去不少力气，比起之前作练习什么都是本身动手写方便多了。要注意一下工程的设置，熟悉它们的做用能够加快编程速度。

Demo代码附件：

http://files.cnblogs.com/cswuyg/%E7%BC%96%E5%86%99DLL%E6%89%80%E5%AD%A6%E6%89%80%E6%80%9D(2)(%E5%AF%BC%E5%87%BA%E7%B1%BB).rar

参考资料：

http://www.codeproject.com/KB/cpp/howto_export_cpp_classes.aspx

编写DLL所学所思(1)——导出函数

2010.8.31~2010.9.1总结

2011.9.28~30整理

烛秋

动态连接库的使用有两种方式，一种是显式调用。一种是隐式调用。

（1）显式调用：使用LoadLibrary载入动态连接库、使用GetProcAddress获取某函数地址。

（2）隐式调用：可使用#pragma comment(lib, “XX.lib”)的方式，也能够直接将XX.lib加入到工程中。

DLL的编写

编写dll时，有个重要的问题须要解决，那就是函数重命名——Name-Mangling。解决方式有两种，一种是直接在代码里解决采用extent”c”、_declspec(dllexport)、#pragma comment(linker, "/export:[Exports Name]=[Mangling Name]")，另外一种是采用def文件。

（1）编写dll时，为何有 extern “C”

缘由：由于C和C++的重命名规则是不同的。这种重命名称为“Name-Mangling”（名字修饰或名字改编、标识符重命名，有些人翻译为“名字粉碎法”，这翻译显得有些莫名其妙）

听说，C++标准并无规定Name-Mangling的方案，因此不一样编译器使用的是不一样的，例如：Borland C++跟Mircrosoft C++就不一样，并且可能不一样版本的编译器他们的Name-Mangling规则也是不一样的。这样的话，不一样编译器编译出来的目标文件.obj 是不通用的，由于同一个函数，使用不一样的Name-Mangling在obj文件中就会有不一样的名字。若是DLL里的函数重命名规则跟DLL的使用者采用的重命名规则不一致，那就会找不到这个函数。

C标准规定了C语言Name-Mangling的规范（林锐的书有这样说过）。这样就使得，任何一个支持c语言的编译器，它编译出来的obj文件能够共享，连接成可执行文件。这是一种标准，若是DLL跟其使用者都采用这种约定，那么就能够解决函数重命名规则不一致致使的错误。

影响符号名的除了C++和C的区别、编译器的区别以外，还要考虑调用约定致使的Name Mangling。如extern “c” __stdcall的调用方式就会在原来函数名上加上写表示参数的符号，而extern “c” __cdecl则不会附加额外的符号。

dll中的函数在被调用时是以函数名或函数编号的方式被索引的。这就意味着采用某编译器的C++的Name-Mangling方式产生的dll文件可能不通用。由于它们的函数名重命名方式不一样。为了使得dll能够通用些，不少时候都要使用C的Name-Mangling方式，便是对每个导出函数声明为extern “C”，并且采用_stdcall调用约定，接着还须要对导出函数进行重命名，以便导出不加修饰的函数名。

注意到extern “C”的做用是为了解决函数符号名的问题，这对于动态连接库的制造者和动态连接库的使用者都须要遵照的规则。

动态连接库的显式装入就是经过GetProcAddress函数，依据动态连接库句柄和函数名，获取函数地址。由于GetProcAddress仅是操做系统相关，可能会操做各类各样的编译器产生的dll，它的参数里的函数名是原本来本的函数名，没有任何修饰，因此通常状况下须要确保dll’里的函数名是原始的函数名。分两步：一，若是导出函数使用了extern”C” _cdecl，那么就不须要再重命名了，这个时候dll里的名字就是原始名字；若是使用了extern”C” _stdcall，这时候dll中的函数名被修饰了，就须要重命名。2、重命名的方式有两种，要么使用*.def文件，在文件外修正，要么使用#pragma，在代码里给函数别名。

（2）_declspec(dllexport)和_declspec(dllimport)的做用

_declspec还有另外的用途，这里只讨论跟dll相关的使用。正如括号里的关键字同样，导出和导入。_declspec(dllexport)用在dll上，用于说明这是导出的函数。而_declspec(dllimport)用在调用dll的程序中，用于说明这是从dll中导入的函数。

由于dll中必须说明函数要用于导出，因此_declspec(dllexport)颇有必要。可是能够换一种方式，可使用def文件来讲明哪些函数用于导出，同时def文件里边还有函数的编号。

而使用_declspec(dllimport)却不是必须的，可是建议这么作。由于若是不用_declspec(dllimport)来讲明该函数是从dll导入的，那么编译器就不知道这个函数到底在哪里，生成的exe里会有一个call XX的指令，这个XX是一个常数地址，XX地址处是一个jmp dword ptr[XXXX]的指令，跳转到该函数的函数体处，显然这样就平白无故多了一次中间的跳转。若是使用了_declspec(dllimport)来讲明，那么就直接产生call dword ptr[XXX]，这样就不会有多余的跳转了。（参考《加密与解密》第三版279页）

（3）__stdcall带来的影响

这是一种函数的调用方式。默认状况下VC使用的是__cdecl的函数调用方式，若是产生的dll只会给C/C++程序使用，那么就不必定义为__stdcall调用方式，若是要给Win32汇编使用（或者其余的__stdcall调用方式的程序），那么就可使用__stdcall。这个可能不是很重要，由于能够本身在调用函数的时候设置函数调用的规则。像VC就能够设置函数的调用方式，因此能够方便的使用win32汇编产生的dll。不过__stdcall这调用约定会Name-Mangling，因此我以为用VC默认的调用约定简便些。可是，若是既要__stdcall调用约定，又要函数名不给修饰，那可使用*.def文件，或者在代码里#pragma的方式给函数提供别名（这种方式须要知道修饰后的函数名是什么）。

举例：

·extern “C” __declspec(dllexport) bool __stdcall cswuyg();

·extern “C”__declspec(dllimport) bool __stdcall cswuyg();

·#pragma comment(linker, "/export:cswuyg=_cswuyg@0")

（4）*.def文件的用途

指定导出函数，并告知编译器不要以修饰后的函数名做为导出函数名，而以指定的函数名导出函数（好比有函数func，让编译器处理后函数名仍为func）。这样，就能够避免因为microsoft VC++编译器的独特处理方式而引发的连接错误。

也就是说，使用了def文件，那就不须要extern “C”了，也能够不须要__declspec(dllexport)了（不过，dll的制造者除了提供dll以外，还要提供头文件，须要在头文件里加上这extern”C”和调用约定，由于使用者须要跟制造者遵照一样的规则，除非使用者和制造者使用的是一样的编译器并对调用约定无特殊要求）。

举例def文件格式：

LIBRARY XX(dll名称这个并非必须的，但必须确保跟生成的dll名称同样)

EXPORTS

[函数名] @ [函数序号]

编写好以后加入到VC的项目中，就能够了。

另外，要注意的是，若是要使用__stdcall，那么就必须在代码里使用上__stdcall，由于*.def文件只负责修改函数名称，不负责调用约定。

也就是说，def文件只管函数名，无论函数平衡堆栈的方式。

若是把*.def文件加入到工程以后，连接的时候并无自动把它加进去。那么能够这样作：

手动的在link添加：

1）工程的propertiesàConfiguration PropertiesàLinkeràCommand Lineà在“Additional options”里加上：/def:[完整文件名].def

2）工程的propertiesàConfiguration PropertiesàLinkeràInputàModule Definition File里加上[完整文件名].def

注意到：即使是使用C的名称修饰方式，最终产生的函数名称也多是会被修饰的。例如，在VC下，_stdcall的调用方式，就会对函数名称进行修饰，前面加‘_’，后面加上参数相关的其余东西。因此使用*.def文件对函数进行命名颇有用，很重要。

（5）、DllMain函数

每个动态连接库都会有一个DllMain函数。若是在编程的时候没有定义DllMain函数，那么编译器会给你加上去。

DllMain函数格式：

BOOL APIENTRY DllMain( HANDLE hModule,

DWORD ul_reason_for_call,

LPVOID lpReserved

)

{

switch(ul_reason_for_call)

{

case DLL_PROCESS_ATTACH:

printf("\nprocess attach of dll");

break;

case DLL_THREAD_ATTACH:

printf("\nthread attach of dll");

break;

case DLL_THREAD_DETACH:

printf("\nthread detach of dll");

break;

case DLL_PROCESS_DETACH:

printf("\nprocess detach of dll");

break;

}

return TRUE;

}

（6）、不少都还没学，如：导出Class、导出变量、DLL更高级的应用。目前先了解点基础知识。之后补上。

2011-8-14补充

编写dll可使用.def文件对导出的函数名进行命名。

一、动态装入dll，重命名（*.def）的必要性？

由于导出的函数尽量使用__stdcall的调用方式。而__stdcall的调用方式，不管是C的Name Mangling，仍是C++的Name Mangling都会对函数名进行修饰。因此，采用__stdcall调用方式以后，必须使用*.def文件对函数名重命名，否则就不能使用GetProcAddress()经过函数名获取函数指针。

二、隐式调用时，头文件要注意的地方？

由于使用静态装入，须要有头文件声明这个要被使用的dll中的函数，若是声明中指定了__stdcall或者extern “C”，那么在调用这个函数的时候，编译器就经过Name Mangling以后的函数名去.lib中找这个函数，*.def中的内容是对*.lib里函数的名称不产生做用，*.def文件里的函数重命名只对dll有用。这就有lib 跟dll里函数名不一致的问题了，但并不会产生影响，DLL的制造者跟使用者采用的是一致函数声明。

三、因此到底要不要使用__stdcall 呢？

我看到一些代码里是没有使用__stdcall的。若是不使用__stdcall，而使用默认的调用约定_cdecl，而且有extern ”C”。那么VC是不会任何修饰的。这样子生成的dll里的函数名就是原来的函数名。也就能够不使用.def文件了。

也有一些要求必须使用__stdcall，例如com相关的东西、系统的回调函数。具体看有没有须要。

四、导出函数别名怎么写？

能够在.def文件里对函数名写一个别名。

例如：

EXPORTS

cswuygTest（别名） = _showfun@4(要导出的函数)

或者：

#pragma comment(linker, "/export:[别名] =[NameMangling后的名称]")

这样作就能够随便修改别名了，不会出现找不到符号的错误。

五、用不用*.def文件？

若是采用VC默认的调用约定，能够不用*.def文件，若是要采用__stdcall调用约定，又不想函数名被修饰，那就采用*.def文件吧,另外一种在代码里写的重命名的方式不够方便。

六、什么状况下（不）须要考虑函数重命名的问题？

1）、隐式调用（经过lib）

若是dll的制造者跟dll的使用者采用一样的语言、一样编程环境，那么就不须要考虑函数重命名。使用者在调用函数的时候，经过Name Mangling后的函数名能在lib里找到该函数。

若是dll的制造者跟dll使用不一样的语言、或者不一样的编译器，那就须要考虑重命名了。

2）、显示调用（经过GetProcessAddress）

这绝对是必须考虑函数重命名的。

七、总结

总的来讲，在编写DLL的时候，写个头文件，头文件里声明函数的NameMingling方式、调用约定（主要是为了隐式调用）。再写个*.def文件把函数重命名了（主要是为了显式调用）。提供*.DLL\*.lib\*.h给dll的使用者，这样不管是隐式的调用，仍是显式的调用，均可以方便的进行。

附：

一个简单DLL导出函数的例子：http://files.cnblogs.com/cswuyg/%E7%BC%96%E5%86%99DLL%E6%89%80%E5%AD%A6%E6%89%80%E6%80%9D.rar

学习资料：

http://www.cnblogs.com/dongzhiquan/archive/2009/08/04/1994764.html

http://topic.csdn.net/u/20081126/14/70ac75b3-6e79-4c48-b9fe-918dce147484.html

C++ DLL导出类 知识大全

编写DLL所学所思(1)——导出函数

动态连接库的使用有两种方式，一种是显式调用。一种是隐式调用。

DLL的编写

（1）编写dll时，为何有 extern “C”

（2）_declspec(dllexport)和_declspec(dllimport)的做用

（3）__stdcall带来的影响

（4）*.def文件的用途

（5）、DllMain函数

（6）、不少都还没学，如：导出Class、导出变量、DLL更高级的应用。目前先了解点基础知识。之后补上。

2011-8-14补充

一、动态装入dll，重命名（*.def）的必要性？

二、隐式调用时，头文件要注意的地方？

三、因此到底要不要使用__stdcall 呢？

四、导出函数别名怎么写？

五、用不用*.def文件？

六、什么状况下（不）须要考虑函数重命名的问题？

七、总结

学习资料：

C++ DLL导出类知识大全