user-0 提问: 想请教一个关于头文件中函数申明与编译时是怎样寻找函数定义的问题？

回复:
user: user-1
content: 只需声明原型就可以了，寻找真正的函数实现（就是找到符号地址）是链接器的工作。  其实，楼主的想法是有些道理的，楼主觉得总要告诉编链接器printf函数实现的coff的位置吧？  没错，但这些编译器都会将printf的定义所在的lib库设定为默认链接，你不管它，它就默默给你加上去了。  如果你使用一些非默认的lib，就需要你手工告诉连接器了，比如，当你使用输入法的相关API，就要加入Imm32.lib，这需要你人工在linker选项里加入。  同理，你自己做的lib，也要你手工引入。  你也可以在代码里插入linker注释，  (不同编译器写法不尽相同) #pragma comment(lib, "abc.lib"）  这样其实是在预处理阶段做了一个记录，让最后的链接阶段做这个操作而已。  但我不建议你使用这种预处理注释，还是老老实实地在工程属性的linker选项里加入需要链接的lib。

user: user-2
content: 这是链接器的事情 将所有的obj lib 一起进行链接操作。

user: user-3
content: 编译的时候, .cpp以及 这个.cpp里 包含的所有.h里的代码，都会被扩展到.cpp文件里，然后被变异成一个.obj文件。(PE格式，并不一定能执行)  ....然后再链接....

user: user-4
content: 《Windows PE权威指南》

user: user-4
content: Windows下使用 dumpbin.exe /EXPORTS xxx.dll dumpbin.exe /EXPORTS xxx.lib 查看xxx.dll和xxx.lib文件中都导出了哪些函数。

user: user-4
content: dll 导出函数名的那些事 关键字：　VC++ 　DLL  导出函数　 经常使用VC6的Dependency查看DLL导出函数的名字，会发现有DLL导出函数的名字有时大不相同，导致不同的原因大多是和编译DLL时候指定DLL导出函数的界定符有关系。 VC++支持两种语言：即C/C++，这也是造成DLL导出函数差异的根源 我们用VS2008新建个DLL工程，工程名为"TestDLL" 把默认的源文件后缀 .CPP改为.C（C文件） 输入测试代码如下： 01 int _stdcall MyFunction(int iVariant) 02 { 03 return 0; 04 } 为了导出上面这个函数，我们有以下几个方法： 1. 使用传统的模块定义文件 (.def) 新建一个 后缀为.def的文本文件(这里建一个TestDll.Def)，文件内容为： LIBRARY TestDll EXPORTS MyFunction 在 Link 时指定输入依赖文件：/DEF:"TestDll.Def" 2. Visual C++ 提供的方便方法 在01行的int 前加入 __declspec(dllexport) 关键字 通过以上两种方法，我们就可以导出MyFunction函数。 我们用Dependency查看导出的函数： 第一种方法导出的函数为： MyFunction 第二种方法导出的函数为： _MyFunction@4 __stdcall会使导出函数名字前面加一个下划线，后面加一个@再加上参数的字节数，比如_MyFunction@4的参数（int iVariant）就是4个字节 __fastcall与 __stdcall类似，不过前面没有下划线，而是一个@，比如@MyFunction@4 __cdecl则是始函数名。 小结：如果要导出C文件中的函数，并且不让编译器改动函数名，用def文件导出函数。 下面我们来看一下C++文件 我们用VS2008新建个DLL工程，工程名为"TestDLL" 默认的源文件后缀为 .CPP （即C++文件）。 输入测试代码如下： 01 int _stdcall MyFunction(int iVariant) 02 { 03 return 0; 04 } 为了导出上面这个函数，我们有以下几个方法： 3. 使用传统的模块定义文件 (.def) 新建一个 后缀为.def的文本文件(这里建一个TestDll.Def)，文件内容为： LIBRARY TestDll EXPORTS MyFunction 在 Link 时指定输入依赖文件：/DEF:"TestDll.Def" 4. Visual C++ 提供的方便方法 在01行的int 前加入 __declspec(dllexport) 关键字 通过以上两种方法，我们就可以导出MyFunction函数。 我们用Dependency查看导出的函数： 第一种方法导出的函数为： MyFunction 第二种方法导出的函数为： ?MyFunction@@YGHH@Z 可以看到 第二种方法得到的 导出函数名 并不是我们想要的，如果在exe中用显示方法（LoadLibrary、GetProcAddress）调用 MyFunction 肯定会失败。 但是用引入库(*.LIB)的方式调用，则编译器自动处理转换函数名，所以总是没有问题。 解决这个问题的方法是： 用VC 提供的预处理指示符 "#pragma" 来指定链接选项。 如下： #pragma comment(linker, "/EXPORT:MyFunction=?MyFunction@@YGHH@Z") 这时，就会发现导出的函数名字表中已经有了我们想要的MyFunction。但我们发现原来的那个 ?MyFunction@@YGHH@Z 函数还在，这时就可以把 __declspec() 修饰去掉，只需要 pragma 指令即可。 而且还可以使如下形式： #pragma comment(linker, "/EXPORT:MyFunction=_MyFunction@4,PRIVATE") PRIVATE 的作用与其在 def 文件中的作用一样。更多的#pragram请查看MSDN。 小结：如果要导出C++文件中的函数，并且不让编译器改动函数名，用def文件导出函数。 同时可以用#pragma指令（C 中也可以用）。 总结： C++编译器在生成DLL时，会对导出的函数进行名字改编，并且不同的编译器使用的改编规则不一样，因此改编后的名字也是不同的（一般涉及到C++ 中的重载等）。 如果利用不同编译器分别生成DLL和访问DLL的exe程序，后者在访问该DLL的导出函数时就会出现问题。如上例中函数MyFunction在C++编译器改编后的名字是?MyFunction@@YGHH@Z。我们希望编译后的名字不发生改变，这里有几种方法。 第一种方法是通过一个称为模块定义文件DEF来解决。 LIBRARY TestDll EXPORTS MyFunction LIBRARY 用来指定动态链接库内部名称。该名称与生成的动态链接库名一定要匹配，这句代码不是必须的。 EXPORTS说明了DLL将要导出的函数，以及为这些导出函数指定的符号名。 第二种是定义导出函数时加上限定符：extern "C" 如：#define DLLEXPORT_API extern "C" _declspec(dllexport) 但extern "C"只解决了C和C++语方之间调用的问题(extern "C" 是告诉编译器，让它按C的方式编译)，它只能用于导出全局函数这种情况 而不能导出一个类的成员函数。 同时如果导出函数的调用约定发生改变，即使使用extern "C"，编译后的函数名还是会发生改变。例如上面我们加入_stdcall关键字说明调用约定（标准调用约定，也就是WINAPI调用约定）。 #define DLLEXPORT_API extern "C" _declspec(dllexport) 01 DLLEXPORT_API int _stdcall MyFunction(int iVariant) 02 { 03 return 0; 04 } 编译后函数名MyFunction改编成了_MyFunction@4 通过第一种方法模块定义文件的方式DLL编译后导出函数名不会发生改变。 DLL(动态库)导出函数名乱码含义 C++编译时函数名修饰约定规则：   __stdcall调用约定：   1、以"?"标识函数名的开始，后跟函数名；    2、函数名后面以"@@YG"标识参数表的开始，后跟参数表；    3、参数表以代号表示：   X--void   D--char   E--unsigned char   F--short   H--int   I--unsigned int   J--long   K--unsigned long   M--float   N--double   _N--bool   ....   PA--表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以"0"代替，一个"0"代表一次重复；   4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前；    5、参数表后以"@Z"标识整个名字的结束，如果该函数无参数，则以"Z"标识结束。   其格式为"?functionname@@YG*****@Z"或"?functionname@@YG*XZ"，例如                       int Test1(char *var1, unsigned long)-----"?Test1@@YGHPADK@Z"                      void Test2()-----"?Test2@@YGXXZ"    __cdecl调用约定：   规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YA"。   __fastcall调用约定：   规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YI"。   如果要用DEF文件输出一个"C++"类，则把要输出的数据和成员的修饰名都写入.def模块定义文件   所以...   通过def文件来导出C++类是很麻烦的,并且这个修饰名是不可避免的

user: user-0
content: 引用 6 楼 zhao4zhong1 的回复:《程序员的自我修养——链接、装载与库》 这本书有在看呢，看到前面两章了，不过感觉时间太紧了，是把pdf放在手机里面蹲厕所的时候看的，

user: user-0
content: 引用 1 楼 lile1234_show 的回复:编译的时候, .cpp以及 这个.cpp里 包含的所有.h里的代码，都会被扩展到.cpp文件里，然后被变异成一个.obj文件。(PE格式，并不一定能执行)  ....然后再链接.... 引用 2 楼 akirya 的回复:这是链接器的事情 将所有的obj lib 一起进行链接操作。 引用 4 楼 user-6 的回复:还有一个链接中间文件的过程的！(库文件) 引用 5 楼 turingo 的回复:绝大部分编译器默认都会直接链接libc（C标准库），printf也包含在其中。  [quote=引用 楼主 Enter_ 的回复:] 例如：printf函数是申明在《stdio.h》文件中的，但是我们在编写程序时，却只是包含了头文件《stdio.h》，里面没有它的定义，但是却可以正常的输出，这是为什么呢？是关于编译器的问题么？？程序是如何知道printf函数是在哪里定义的呢？一个文件一个文件的挨着查找么？还是直接查找包含头文件《stdio.h》的c文件呢？  它的定义是包含在类似如下一个文件中的： 文件名：printf.c  #include "stdio.h" int printf (const char *, ...) {....}[/quote]  引用 3 楼 sinservice 的回复:只需声明原型就可以了，寻找真正的函数实现（就是找到符号地址）是链接器的工作。  其实，楼主的想法是有些道理的，楼主觉得总要告诉编链接器printf函数实现的coff的位置吧？  没错，但这些编译器都会将printf的定义所在的lib库设定为默认链接，你不管它，它就默默给你加上去了。  如果你使用一些非默认的lib，就需要你手工告诉连接器了，比如，当你使用输入法的相关API，就要加入Imm32.lib，这需要你人工在linker选项里加入。  同理，你自己做的lib，也要你手工引入。  你也可以在代码里插入linker注释，  (不同编译器写法不尽相同) #pragma comment(lib, "abc.lib"）  这样其实是在预处理阶段做了一个记录，让最后的链接阶段做这个操作而已。  但我不建议你使用这种预处理注释，还是老老实实地在工程属性的linker选项里加入需要链接的lib。 嗯，谢谢哈！现在脑袋里面有个大体的逻辑了！！

user: user-4
content: 《程序员的自我修养——链接、装载与库》

user: user-5
content: 绝大部分编译器默认都会直接链接libc（C标准库），printf也包含在其中。  引用 楼主 Enter_ 的回复:例如：printf函数是申明在《stdio.h》文件中的，但是我们在编写程序时，却只是包含了头文件《stdio.h》，里面没有它的定义，但是却可以正常的输出，这是为什么呢？是关于编译器的问题么？？程序是如何知道printf函数是在哪里定义的呢？一个文件一个文件的挨着查找么？还是直接查找包含头文件《stdio.h》的c文件呢？  它的定义是包含在类似如下一个文件中的： 文件名：printf.c  #include "stdio.h" int printf (const char *, ...) {....}

user: user-6
content: 还有一个链接中间文件的过程的！(库文件)