本文主要是介绍再议：__cdecl与__stdcall 调用约定在动态链接库调用中不同的表现，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
| dll中函数声明 | dll中函数名 |
|
| void __declspec(dllexport) add(int, int) | ?add@@YAXHH@Z |
|
| extern "C" void __declspec(dllexport) add(int, int) | add |
|
| void __declspec(dllexport) __stdcall add(int, int) | ?add@@YGXHH@Z |
|
| extern "C" void __declspec(dllexport) __stdcall add(int, int) | _add@8 |
|
主调程序必需用相同的符号调用，但c++各个编译器生成符号不同，因此为了方便，也为了与c的混合编程，一般用c++编译器编写dll时，
声明为 extern "C" ，而主调程序也同时声明为extern "C" （或 不声明，只靠C++编译器生成一个混乱的名称，但这是就要求 dll 的编译器与主调程序的编译器相同，
则它们生成的混乱名称也相同）
即使是 extern "C" 碰到 stdcall 时，当采用GetProcAddress也找不到 add 这个函数，（因为名称已经变掉了，静态调用时，编译器也会按stdcall生成的函数名_add@8 在外部查找函数，所以不影响，但动态调用则不行），无语了，这时候要 def 文件 登场
当启用def文件后，不再需要__declspec(dllexport)申明相关函数为导出函数
LIBRARY "xxx"
EXPORTS
add
dll中文件名都变成add，但不影响导入库lib文件，也就是静态调用动态链接库时，仍要确保 两边 编译器 生成的函数名一样，所以通常推荐两边同时声明 extern "C" ，不然很难确保不同的c++编译器生成相同的函数名，这里为了搞清问题，两边使用同一种编译器，考虑了四种情况。
例子：
在动态链接库 xxx.dll 代码中，（已启用def文件，所以省略__declspec(dllexport)）
void add(int, int)
{
return ;
}以c++方式导出函数，编译器处理为?add@@YAXHH@Z
主调程序中，GetProcAddress调用成功，静态调用时，函数申明分别为
| 函数申明 | 错误 | |
| extern "C" void add(int,int); | 无法解析的外部符号_add | 链接不通过 |
| void add(int,int); | /（同一个编译器给了个同一函数名来外部链接） | 链接通过 |
在xxx.dll 代码中，
extern "C" void add(int, int)
{
return ;
}以c方式导出函数，编译器处理为_add(为什么不是add?)
因为启用了def文件，所以主调程序的GetProcAddress无论如何都成功，而静态调用情况如下：
| 函数声明 | 错误 | |
| extern "C" void add(int,int); | /同样生成_add外部链接成功 | 链接通过 |
| void add(int,int); | "void __cdecl add(int,int)" (?add@@YAXHH@Z) | 链接不通过 |
参考：
http://blog.csdn.net/wujian53/article/details/706975
http://hi.baidu.com/luosiyong/item/88a97b0e3bd0ee8802ce1b0b
http://blog.csdn.net/friday5pm/article/details/1532212
相关代码下载，dll 文件的位置需在运行时再调整，否则提示找不到xx.dll
http://download.csdn.net/detail/silyvin/5467251
这篇关于再议：__cdecl与__stdcall 调用约定在动态链接库调用中不同的表现的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
