windows环境DLL链接问题之二：C/C++修饰符问题

在windows环境DLL链接问题之一中，简要了讲述了Dllimport的问题，但是贴在其中的代码还没有详细解释，现在就来看一下吧！

为了解释C/C++修饰符的问题，简单了写了个测试文件，用来测试DLL文件的功能。代码如：

// DllCommain.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "../DllCom/DllCom.h"

#pragma comment(lib,"..\\Test\\Debug\\DllCom.lib")

int _tmain(int argc, _TCHAR* argv[])
{
#ifdef __cplusplus
printf("main c++ definition!\n");
#else
printf("main c++ not definition!\n");
#endif
printf("%s\n",GetValueString(0));
SetValueString("hello big WORLD!");
printf("%s\n",GetValueString(0));
getchar();
return 0;
}

1. __cdecl修饰符
C/C++调用默认的修饰符，也就是说：如果你写了形如   int read();  这样的函数，也就等于  int __cdecl read();  当编译器根据源文件的内容生成.obj文件时，read这个函数名就会按照_cdecl的调用约定更改。

在windows环境DLL链接问题之一中，我们首先编译生成DLL文件和lib文件，由于VS编译器是按照扩展名来识别源文件的，因此这些文件都被看做为C++源文件，这样__cplusplus也就处于定义状态。
这样我们就告诉编译器，虽然是C++源文件，但是我们希望它按照C文件的规则（extern "C"的作用）生成函数修饰符。
使用VS提供的Dependency工具查看Dll文件的输出函数列表：



使用dumpbin.exe文件查看DllCommain.cpp生成的DllCommain.obj文件：



我们在看一看DllCommain.exe的内容：



DllCommain.exe确实输入了DllCom.dll中的这两个函数，而且经过修饰的名称就是原来的函数名。这就是extern "C"和__cdecl结合的作用了！

现在我们去掉extern “C”这个修饰，再来看看输出有什么不同？？？
为了简便，将Dllcom.h文件和DllCom.cpp文件中#ifdef __cplusplus改成#ifndef[b]__cplusplus[/b]
看看现在DLLcom.dll中的输出：




DllCommain。obj文件的内容：






直接查看DllCommain.exe文件的内容：




这就是C++编译器对C++源代码的默认修饰结果了。
如果你的调用DLL中函数的链接出现错误，如unresolved external symbol "void __cdecl
SetValueString(char const *)" (?SetValueString@@YAXPBD@Z)
referenced in function _wmain,这句错误是由于我重新编译了使用extern
"C"的DLL文件，导致main函数在编译时生成的修饰符?SetValueString@@YAXPBD@Z在DLL文件中找不到！