原文来源：
http://www.codeproject.com/KB/cpp/howto_export_cpp_classes.aspx
译文来源：http://blog.csdn.net/clever101
C++语言毕竟能和Windows DLLs能够和平共处。
介绍
自从Windows的开始阶段动态链接库（DLL）就是Windows平台的一个组成部分。动态链接库允许在一个独立的模块中封装一系列的功能函数然后以一个显式的C函数列表提供外部使用者使用。在上个世纪80年代，当Windows
DLLs面世时，对于广大开发者而言只有C语言是切实可行的开发手段。所以，
Windows DLLs很自然地以C函数和数据的形式向外部暴露功能。从本质来说，一个DLL可以由任何语言实现，但是为了使DLL用于其它的语言和环境之下，一个DLL接口必须后退到最低要求的母体——C语言。
使用C接口并不自动意味一个开发者应该应该放弃面向对象的开发方式。甚至C接口也能用于真正的面向对象编程，尽管它有可能被认为是一种单调乏味的实现方式。很显然世界上使用人数排第二的编程语言是C++，但它却不得不被DLL所诱惑。然而，和C语言相反，在调用者和被调用者之间的二进制接口被很好的定义并被广泛接受，但是在C++的世界里却没有可识别的应用程序二进制接口。实际上，由一个C++编译器产生的二进制代码并不能被其它C++编译器兼容。再者，在同一个编译器但不同版本的二进制代码也是互不兼容的。所有这些导致从一个DLL中一个C++类简直就是一个冒险。
这篇文章就是演示几种从一个DLL模块中导出C++类的方法。源码演示了导出虚构的Xyz对象的不同技巧。Xyz对象非常简单，只有一个函数：Foo。
下面是Xyz对象的图解：
|
Xyz |
|
int |
Xyz对象在一个DLL里实现，这个DLL能作为一个分布式系统供范围很广的客户端使用。一个用户能以下面三种方式调用Xyz的功能：
使用纯C
使用一个规则的C++类
使用一个抽象的C++接口
源码（译注：文章附带的源码）包含两个工程：
XyzLibrary
– 一个DLL工程
XyzExecutable
– 一个Win32
使用"XyzLibrary.dll"的控制台程序
XyzLibrary工程使用下列方便的宏导出它的代码：
#if defined(XYZLIBRARY_EXPORT) // inside DLL
#
#else // outside DLL
#
#endif
XYZLIBRARY_EXPORT标识符仅仅在XyzLibrary工程定义，因此在XYZAPI宏在DLL生成时被扩展为__declspec(dllexport)而在客户程序生成时被扩展为__declspec(dllimport)。
C语言方式
句柄
经典的C语言方式进行面向对象编程的一种方式就是使用晦涩的指针，比如句柄。一个用户能够使用一个函数创建一个对象。实际上这个函数返回的是这个对象的一个句柄。接着用户能够调用这个对象相关的各种操作函数只要这个函数能够接受这个句柄作为它的一个参数。一个很好的例子就是在Win32窗口相关的API中句柄的习惯是使用一个HWND句柄来代表一个窗口。虚构的Xyz对象通过下面这样一种方式导出一个C接口：
typedef tagXYZHANDLE {} * XYZHANDLE;
//
创建一个Xyz对象实例的函数
XYZAPI XYZHANDLE APIENTRY GetXyz(VOID);
//
调用Xyz.Foo函数
XYZAPI INT APIENTRY XyzFoo(XYZHANDLE handle, INT n);
//
释放Xyz实例和占用的资源
XYZAPI VOID APIENTRY XyzRelease(XYZHANDLE handle);
// APIENTRY is defined as __stdcall in WinDef.h header.
下面是一个客户端调用的C代码：
#include "XyzLibrary.h"
...
XYZHANDLE hXyz = GetXyz();
if(hXyz)
{
}
使用这种方式，一个DLL必须提供显式的对象构建和删除函数。
调用协定
对于所有的导出函数记住它们调用协定是重要的。对于很多初学者来说忘记添加调用协定是非常普遍的错误。只要客户端的调用协定和DLL的调用协定匹配，一切都能运行。但是，一旦客户端改变了它的调用协定，开发者将会产生一个难以察觉的直到运行时才发生的错误。XyzLibrary工程使用一个APIENTRY宏，这个宏在"WinDef.h"这个头文件里被定义为__stdcall。
异常安全性
在DLL范围内不允许发生C++异常。在一段时间内，C语言不识别C++的异常，并且不能正确处理它们。假如一个对象的方法需要报告一个错误，这时一个返回码需要用到。
优点
一个DLL能被最广泛的合适的开发者所使用。几乎每一种现代编程语言都支持纯C函数的互用性。
一个DLL的C运行时库和它的客户端是互相独立的。因为资源的获取和释放完全发生在DLL模块的内部，所以一个客户端不受一个DLL的C运行时库选择的影响。
缺点
获取正确对象的合适的方法的责任落在DLL的使用者的肩上。比如在下面的代码片断，编译器不能捕捉到其中发生的错误：
XYZHANDLE h = GetSomeOtherObject();
XyzFoo(h, 42);
显式要求创建和摧毁一个对象的实例。其中特别烦人的是对象实例的删除。客户端必须极仔细地在一个函数的退出点调用XyzRelease函数。假如开发者忘记调用XyzRelease函数，那时资源就会泄露，因为编译器不能跟踪一个对象实例的生命周期。那些支持析构函数或垃圾收集器的语言通过在C接口上作一层封装有助于降低这个问题发生的概率。
假如一个对象的函数返回或接受其它对象作为参数，那时DLL作者也就不得不为这些对象提供一个正确的C接口。假如退回到最大限度的复用，也就是C语言，那么只有以字节创建的类型（如int,
double, char*等等）可以作为返回类型和函数参数
在Windows平台上几乎每一个现代的编译器都支持从一个DLL中导出一个类。导出一个类和导出一个C函数非常相似。用那种方法一个开发者被要求做就是在类名之前使用__declspec(dllexport/dllimport)关键字来指定假如整个类都需要被导出，或者在指定的函数声明前指定假如只是特定的类函数需要被导出。这儿有一个代码片断：
//
整个CXyz类被导出，包括它的函数和成员
class XYZAPI CXyz
{
public:
};
//
只有 CXyz::Foo函数被导出
//
class CXyz
{
public:
};
在导出整个类或者它们的方法没有必要显式指定一个调用协定。根据预设，C++编译器使用__thiscall作为类成员函数的调用协定。然而，由于不同的编译器具有不同的命名修饰法则，导出的C++类只能用于同一类型的同一版本的编译器。这儿有一个MS
Visual C++编译器的命名修饰法则的应用实例:
注意这里修饰名是怎样不同于C++原来的名字。下面是屏幕截图显示的是通过使用Dependency Walker工具对同一个DLL的修饰名进行破译得到的：
只有MS Visual C++编译器能使用这个DLL.DLL和客户端代码只有在同一版本的MS
Visual C++编译器才能确保在调用者和被调用者修饰名匹配。这儿有一个客户端代码使用Xyz对象的例子：
#include "XyzLibrary.h"
...
//
客户端使用Xyz对象作为一个规则C++类.
CXyz xyz;
xyz.Foo(42);
正如你所看到的，导出的C++类的用法和其它任何C++类的用法几乎是一样的。没什么特别的。
重要事项：使用一个导出C++类的DLL和使用一个静态库没有什么不同。所有应用于有C++代码编译出来的静态库的规则完全适用于导出C++类的DLL。
所见即所得
一个细心的读者必然已经注意到Dependency Walker工具显示了额外的导出成员，那就是CXyz&
CXyz::operator =(const CXyz&)赋值操作符。在工作你所看到的正是C++的收入（译注：我估计这是原文作者幽默的说法，意思是你没有定义一个=赋值操作符，而编译器帮你自动定义一个，不是收入是什么？）。根据C++标准，每一个类有四个指定的成员函数：
默认构造函数
拷贝构造函数
析构函数
赋值操作符
(operator =)
假如类的作者没有声明同时没有提供这些成员的实现，那么C++编译器会声明它们，并产生一个隐式的默认的实现。在CXyz类，编译器断定它的默认构造函数，拷贝构造函数和析构函数都毫无意义，经过优化后把它们排除掉了。而赋值运算符在优化之后还存活并从DLL中导出。
重要事项：使用__declspec(dllexport)来指定类导出来告诉编译器来尝试导出任何和类相关的东西。它包括所有类的数据成员，所有类的成员函数（或者显式声明，或者由编译器隐式生成），所有类的基类和所有它们的成员。考虑：
class Base
{
};
class Data
{
};
// MS Visual C++ compiler
会发出C4275 warning
，因为没有导出基类
class __declspec(dllexport) Derived :
{
private:
};
在上面的代码片断，编译器会警告你没有导出基类和类的数据成员。所以，为了成功导出一个类，一个开发者被要求导出所有相关基类和所有类的已定义的数据成员。这个滚雪球般的导出要求是一个重大缺点。这也是为什么，比如，导出派生自STL模板类或者使用STL模板类对象作为数据成员是非常困难和令人生厌的。比如一个STL容器比如std::map<>实例可能要求导出数十个额外的内部类。
异常安全性
一个导出的C++类可能会在没有任何错误发生的情况下抛出异常。因为一个DLL和它的客户端使用同一版本的同一类型的编译器的事实，C++异常将在超出DLL的范围进行捕捉和抛出好像DLL没有分界线一样。记住，使用一个带有导出C++代码和使用带有相同代码的静态库是完全一样的。
优点
一个导出的C++类和其它任何C++类的用法是一样的
客户端能毫不费力地捕捉在DLL发生的异常
当在一个DLL模块内有一些小的代码改动时，其它模块也不用重新生成。这对于有着许多复杂难懂代码的大工程是非常有用的。
在一个大工程中按照业务逻辑分成不同的DLL实现可以被认为真正的模块划分的第一步。总的来说，它是使工程达到模块化值得去做的事
缺点
从一个DLL中导出C++类在它的对象和使用者需要保持紧密的联系。DLL应该被视作一个带有考虑到代码依赖的静态库。
客户端代码和DLL都必须和同一版本的CRT（译注：C运行时库）动态连接在一起。为了能够在模块之间修正CRT资源的纪录，这一步是必需的。假如一个客户端和DLL连接到不同版本的CRT，或者静态连接到CRT，那么在一个CRT实例申请的资源有可能在另一个CRT实例中释放。它将损坏CRT实例的内在状态并企图操作外部资源，并很可能导致运行失败。
客户端代码和DLL必须在异常处理和产生达成一致，同时在编译器的异常设置也必须一致
导出C++类要求同时导出这个类的所有相关的东西，包括：所有它的基类、所有类定义的用到的数据成员等等。