long MakeFun(long lFun);
动态库生成的时候采用的函数调用约定是__stdcall，所以编译生成的a.dll中函数MakeFun的调用约定是_stdcall，也就是函数调用时参数从右向左入栈，函数返回时自己还原堆栈。现在某个程序模块b要引用a中的MakeFun，b和a一样使用 C++方式编译，只是b模块的函数调用方式是__cdecl，由于b包含了a提供的头文件中MakeFun函数声明，所以MakeFun在b模块中被其它调用MakeFun的函数认为是__cdecl调用方式，b模块中的这些函数在调用完MakeFun当然要帮着恢复堆栈啦，可是MakeFun已经在结束时自己恢复了堆栈，b模块中的函数这样多此一举就引起了栈指针错误，从而引发堆栈异常。宏观上的现象就是函数调用没有问题（因为参数传递顺序是一样的），MakeFun也完成了自己的功能，只是函数返回后引发错误。解决的方法也很简单，只要保证两个模块的在编译时设置相同的函数调用约定就行了。
在了解了函数调用约定和函数的名修饰规则之后，再来看在C++程序中使用C语言编译的库时经常出现的LNK2001错误就很简单了。还以上面例子的两个模块为例，这一次两个模块在编译的时候都采用__stdcall调用约定，但是a.dll使用C语言的语法编译的（C语言方式），所以a.dll的载入库a.lib中MakeFun函数的名字修饰就是“_MakeFun@4”。b包含了a提供的头文件中MakeFun函数声明，但是由于b采用的是C++语言编译，所以MakeFun在b模块中被按照C++的名字修饰规则命名为“?MakeFun@@YGJJ@Z”，编译过程相安无事，链接程序时c++的链接器就到a.lib中去找“?MakeFun@@YGJJ@Z”，但是a.lib中只有“_MakeFun@4”，没有“?MakeFun@@YGJJ@Z”，于是链接器就报告：
error LNK2001: unresolved external symbol ?MakeFun@@YGJJ@Z
解决的方法和简单，就是要让b模块知道这个函数是C语言编译的，extern"C"可以做到这一点。一个采用C语言编译的库应该考虑到使用这个库的程序可能是C++程序（使用C++编译器），所以在设计头文件时应该注意这一点。通常应该这样声明头文件：
#ifdef _cplusplus
extern "C" {
#endif
long MakeFun(long lFun);
#ifdef _cplusplus
}
#endif
这样C++的编译器就知道MakeFun的修饰名是“_MakeFun@4”，就不会有链接错误了。
许多人不明白，为什么我使用的编译器都是VC的编译器还会产生“error LNK2001”错误？其实，VC的编译器会根据源文件的扩展名选择编译方式，如果文件的扩展名是“.C”，编译器会采用C的语法编译，如果扩展名是 “.cpp”，编译器会使用C++的语法编译程序，所以，最好的方法就是使用extern "C"。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
大家会注意到，像gcc之类的编译器也是采用__cdecl方式，这样对于printf（“％d ％d“，i＋＋，i＋＋）之类的输出结果的疑问就迎刃而解了。
另外引出的一个问题是C语言的变参数函数，对于这部分估计很少大学会涉及到，但这的确是C语言很常见的一个特性，比如printf等。上面提到对于可变参数的支持，需要由函数调用者负责清除栈中的函数参数，但为什么非要这样才可以支持变参数呢？函数调用所涉及到的参数传递是通过栈来实现的，子函数从栈中读取传递给它的参数，如果是从左向右压栈的话那么子函数的最后一个参数在栈顶，然后依次是倒数第二个参数......；如果是从右向左压栈的话那么子函数的第一个参数在栈顶，然后依次是第二个参数......，压栈的顺序问题决定了子函数读取其参数的位置。对于变参数的函数本身来讲，并不知道有几个参数，需要某些信息才能知道，对于printf来讲，就是从前面的格式化字符串fmt来分析出来，一共有几个参数。所以被调函数返回清理栈的方式，对于可变参数是无法实现的，因为被调函数不知道要弹出参数的数量。而对于函数调用着，自己传递给被调函数多少参数（通过把参数压栈）当然是一清二楚的，这样被调函数返回后的堆栈清理也就可以做到准确无误了（不会多也不会少地把参数清理干净）。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
没有评论:
发表评论