使用C/C++語言開發(fā)軟件的程序員經(jīng)常碰到這樣的問題：有時候是程序編譯沒有問題，但是鏈接的時候總是報告函數(shù)不存在（經(jīng)典的LNK 2001錯誤），有時候是程序編譯和鏈接都沒有錯誤，但是只要調用庫中的函數(shù)就會出現(xiàn)堆棧異常。這些現(xiàn)象通常是出現(xiàn)在C和C++的代碼混合使用的情況下或 在C++程序中使用第三方的庫的情況下（不是用C++語言開發(fā)的），其實這都是函數(shù)調用約定（Calling Convention）和函數(shù)名修飾（Decorated Name）規(guī)則惹的禍。函數(shù)調用方式?jīng)Q定了函數(shù)參數(shù)入棧的順序，是由調用者函數(shù)還是被調用函數(shù)負責清除棧中的參數(shù)等問題，而函數(shù)名修飾規(guī)則決定了編譯器使用何種名字修飾方式來區(qū)分不同的函數(shù)，如果函數(shù)之間的調用約定不匹配或者名字修飾不匹配就會產(chǎn)生以上的問題。本文分別對C和C++這兩種編程語言的函數(shù)調 用約定和函數(shù)名修飾規(guī)則進行詳細的解釋，比較了它們的異同之處，并舉例說明了以上問題出現(xiàn)的原因。
函數(shù)調用約定（Calling Convention）
函數(shù)調用約定不僅決定了發(fā)生函數(shù)調用時函數(shù)參數(shù)的入棧順序，還決定了是由調用者函數(shù)還是被調用函數(shù)負責清除棧中的參數(shù)，還原堆棧。函數(shù)調用約定有很多方式，除了常見的__cdecl，__fastcall和__stdcall之外，C++的編譯器還支持thiscall方式，不少C/C++編譯器還支持 naked call方式。這么多函數(shù)調用約定常常令許多程序員很迷惑，到底它們是怎么回事，都是在什么情況下使用呢？下面就分別介紹這幾種函數(shù)調用約定。
1.__cdecl
編譯器的命令行參數(shù)是/Gd。__cdecl方式是C/C++編譯器默認的函數(shù)調用約定，所有非C++成員函數(shù)和那些沒有用__stdcall或 __fastcall聲明的函數(shù)都默認是__cdecl方式，它使用C函數(shù)調用方式，函數(shù)參數(shù)按照從右向左的順序入棧，函數(shù)調用者負責清除棧中的參數(shù)，由 于每次函數(shù)調用都要由編譯器產(chǎn)生清除（還原）堆棧的代碼，所以使用__cdecl方式編譯的程序比使用__stdcall方式編譯的程序要大很多，但是 __cdecl調用方式是由函數(shù)調用者負責清除棧中的函數(shù)參數(shù)，所以這種方式支持可變參數(shù)，比如printf和windows的API wsprintf就是__cdecl調用方式。對于C函數(shù)，__cdecl方式的名字修飾約定是在函數(shù)名稱前添加一個下劃線；對于C++函數(shù)，除非特別使 用extern "C"，C++函數(shù)使用不同的名字修飾方式。
2.__fastcall
編譯器的命令行參數(shù)是/Gr。__fastcall函數(shù)調用約定在可能的情況下使用寄存器傳遞參數(shù)，通常是前兩個 DWORD類型的參數(shù)或較小的參數(shù)使用ECX和EDX寄存器傳遞，其余參數(shù)按照從右向左的順序入棧，被調用函數(shù)在返回之前負責清除棧中的參數(shù)。編譯器使用兩個@修飾函數(shù)名字，后跟十進制數(shù)表示的函數(shù)參數(shù)列表大小，例如：@function_name@number。需要注意的是__fastcall函數(shù)調 用約定在不同的編譯器上可能有不同的實現(xiàn)，比如16位的編譯器和32位的編譯器，另外，在使用內(nèi)嵌匯編代碼時，還要注意不能和編譯器使用的寄存器有沖突。
3.__stdcall
編譯器的命令行參數(shù)是/Gz，__stdcall是Pascal程序的缺省調用方式，大多數(shù)Windows的API也是__stdcall調用約定。 __stdcall函數(shù)調用約定將函數(shù)參數(shù)從右向左入棧，除非使用指針或引用類型的參數(shù)，所有參數(shù)采用傳值方式傳遞，由被調用函數(shù)負責清除棧中的參數(shù)。對于C函數(shù)，__stdcall的名稱修飾方式是在函數(shù)名字前添加下劃線，在函數(shù)名字后添加@和函數(shù)參數(shù)的大小，例如：_functionname@number
4.thiscall
thiscall只用在C++成員函數(shù)的調用，函數(shù)參數(shù)按照從右向左的順序入棧，類實例的this指針通過ECX寄存器傳遞。需要注意的是thiscall不是C++的關鍵字，不能使用thiscall聲明函數(shù)，它只能由編譯器使用。
5.naked call
采用前面幾種函數(shù)調用約定的函數(shù)，編譯器會在必要的時候自動在函數(shù)開始添加保存ESI，EDI，EBX，EBP寄存器的代碼，在退出函數(shù)時恢復這些寄存器 的內(nèi)容，使用naked call方式聲明的函數(shù)不會添加這樣的代碼，這也就是為什么稱其為naked的原因吧。naked call不是類型修飾符，故必須和_declspec共同使用。
VC的編譯環(huán)境默認是使用__cdecl調用約定，也可以在編譯環(huán)境的Project Setting...菜單－》C/C++ ＝》Code Generation項選擇設置函數(shù)調用約定。也可以直接在函數(shù)聲明前添加關鍵字__stdcall、__cdecl或__fastcall等單獨確定函數(shù)的調用方式。在Windows系統(tǒng)上開發(fā)軟件常用到WINAPI宏，它可以根據(jù)編譯設置翻譯成適當?shù)暮瘮?shù)調用約定，在WIN32中，它被定義為 __stdcall。
函數(shù)名字修飾（Decorated Name）方式
函數(shù)的名字修飾（Decorated Name）就是編譯器在編譯期間創(chuàng)建的一個字符串，用來指明函數(shù)的定義或原型。LINK程序或其他工具有時需要指定函數(shù)的名字修飾來定位函數(shù)的正確位置。多數(shù)情況下程序員并不需要知道函數(shù)的名字修飾，LINK程序或其他工具會自動區(qū)分他們。當然，在某些情況下需要指定函數(shù)的名字修飾，例如在C++程序中， 為了讓LINK程序或其他工具能夠匹配到正確的函數(shù)名字，就必須為重載函數(shù)和一些特殊的函數(shù)（如構造函數(shù)和析構函數(shù)）指定名字裝飾。另一種需要指定函數(shù)的名字修飾的情況是在匯編程序中調用C或C++的函數(shù)。如果函數(shù)名字，調用約定，返回值類型或函數(shù)參數(shù)有任何改變，原來的名字修飾就不再有效，必須指定新的名字修飾。C和C++程序的函數(shù)在內(nèi)部使用不同的名字修飾方式，下面將分別介紹這兩種方式。
1. C編譯器的函數(shù)名修飾規(guī)則
對于__stdcall調用約定，編譯器和鏈接器會在輸出函數(shù)名前加上一個下劃線前綴，函數(shù)名后面加上一個“@”符號和其參數(shù)的字節(jié)數(shù)，例如_functionname@number。__cdecl調用約定僅在輸出函數(shù)名前加上一個下劃線前綴，例如_functionname。__fastcall調用約定在輸出函數(shù)名前加上一個“@”符號，后面也是一個“@”符號和其參數(shù)的字節(jié)數(shù)，例如@functionname@number。
2. C++編譯器的函數(shù)名修飾規(guī)則
C++的函數(shù)名修飾規(guī)則有些復雜，但是信息更充分，通過分析修飾名不僅能夠知道函數(shù)的調用方式，返回值類型，參數(shù)個數(shù)甚至參數(shù)類型。不管 __cdecl，__fastcall還是__stdcall調用方式，函數(shù)修飾都是以一個“?”開始，后面緊跟函數(shù)的名字，再后面是參數(shù)表的開始標識和按照參數(shù)類型代號拼出的參數(shù)表。對于__stdcall方式，參數(shù)表的開始標識是“@@YG”，對于__cdecl方式則是“@@YA”，對于__fastcall方式則是“@@YI”。參數(shù)表的拼寫代號如下所示：
X--void
D--char
E--unsigned char
F--short
H--int
I--unsigned int
J--long
K--unsigned long（DWORD）
M--float
N--double
_N--bool
U--struct
....
指 針的方式有些特別，用PA表示指針，用PB表示const類型的指針。后面的代號表明指針類型，如果相同類型的指針連續(xù)出現(xiàn)，以“0”代替，一個“0”代 表一次重復。U表示結構類型，通常后跟結構體的類型名，用“@@”表示結構類型名的結束。函數(shù)的返回值不作特殊處理，它的描述方式和函數(shù)參數(shù)一樣，緊跟著 參數(shù)表的開始標志，也就是說，函數(shù)參數(shù)表的第一項實際上是表示函數(shù)的返回值類型。參數(shù)表后以“@Z”標識整個名字的結束，如果該函數(shù)無參數(shù)，則以“Z”標識結束。下面舉兩個例子，假如有以下函數(shù)聲明：
int Function1(char *var1,unsigned long);
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
其函數(shù)修飾名為“?Function1@@YGHPADK@Z”，而對于函數(shù)聲明：
void Function2();
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
其函數(shù)修飾名則為“?Function2@@YGXXZ” 。
對于C++的類成員函數(shù)（其調用方式是thiscall），函數(shù)的名字修飾與非成員的C++函數(shù)稍有不同，首先就是在函數(shù)名字和參數(shù)表之間插入以“@”字符引導的類名；其次是參數(shù)表的開始標識不同，公有（public）成員函數(shù)的標識是“@@QAE”,保護（protected）成員函數(shù)的標識是“@@IAE”,私有（private）成員函數(shù)的標識是“@@AAE”，如果函數(shù)聲明使用了const關鍵字，則相應的標識應分別為“@@QBE”，“@@IBE”和“@@ABE”。如果參數(shù)類型是類實例的引用，則使用“AAV1”，對于const類型的引用，則使用“ABV1”。下面就以類CTest為例說明C++成員函數(shù)的名字修飾規(guī)則：
class CTest
{
......
private:
void Function(int);
protected:
void CopyInfo(const CTest &src);
public:
long DrawText(HDC hdc, long pos, const TCHAR* text, RGBQUAD color, BYTE bUnder, bool bSet);
long InsightClass(DWORD dwClass) const;
......
};
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
對于成員函數(shù)Function，其函數(shù)修飾名為“?Function@CTest@@AAEXH@Z”，字符串“@@AAE”表示這是一個私有函數(shù)。成員函數(shù)CopyInfo只有一個參數(shù)，是對類CTest的const引用參數(shù)，其函數(shù)修飾名為“?CopyInfo@CTest@@IAEXABV1@@Z”。 DrawText是一個比較復雜的函數(shù)聲明，不僅有字符串參數(shù)，還有結構體參數(shù)和HDC句柄參數(shù)，需要指出的是HDC實際上是一個HDC__結構類型的指 針，這個參數(shù)的表示就是“PAUHDC__@@”，其完整的函數(shù)修飾名為“?DrawText@CTest@@QAEJPAUHDC__@@JPBDUtagRGBQUAD@@E_N@Z”。InsightClass是一個共有的const函數(shù)，它的成員函數(shù)標識是“@@QBE”，完整的修飾名就是“?InsightClass@CTest@@QBEJK@Z”。
無論是C函數(shù)名修飾方式還是C++函數(shù)名修飾方式均不改變輸出函數(shù)名中的字符大小寫，這和PASCAL調用約定不同，PASCAL約定輸出的函數(shù)名無任何修飾且全部大寫。
3.查看函數(shù)的名字修飾
有兩種方式可以檢查你的程序中的函數(shù)的名字修飾：使用編譯輸出列表或使用Dumpbin工具。使用/FAc，/FAs或/FAcs命令行參數(shù)可以讓編譯器 輸出函數(shù)或變量名字列表。使用dumpbin.exe /SYMBOLS命令也可以獲得obj文件或lib文件中的函數(shù)或變量名字列表。此外，還可以使用 undname.exe 將修飾名轉換為未修飾形式。
函數(shù)調用約定和名字修飾規(guī)則不匹配引起的常見問題
函數(shù)調用時如果出現(xiàn)堆棧異常，十有八九是由于函數(shù)調用約定不匹配引起的。比如動態(tài)鏈接庫a有以下導出函數(shù)：
long MakeFun(long lFun);
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
動態(tài)庫生成的時候采用的函數(shù)調用約定是__stdcall，所以編譯生成的a.dll中函數(shù)MakeFun的調用約 定是_stdcall，也就是函數(shù)調用時參數(shù)從右向左入棧，函數(shù)返回時自己還原堆?！，F(xiàn)在某個程序模塊b要引用a中的MakeFun，b和a一樣使用 C++方式編譯，只是b模塊的函數(shù)調用方式是__cdecl，由于b包含了a提供的頭文件中MakeFun函數(shù)聲明，所以MakeFun在b模塊中被其它 調用MakeFun的函數(shù)認為是__cdecl調用方式，b模塊中的這些函數(shù)在調用完MakeFun當然要幫著恢復堆棧啦，可是MakeFun已經(jīng)在結束 時自己恢復了堆棧，b模塊中的函數(shù)這樣多此一舉就引起了棧指針錯誤，從而引發(fā)堆棧異常。宏觀上的現(xiàn)象就是函數(shù)調用沒有問題（因為參數(shù)傳遞順序是一樣 的），MakeFun也完成了自己的功能，只是函數(shù)返回后引發(fā)錯誤。解決的方法也很簡單，只要保證兩個模塊的在編譯時設置相同的函數(shù)調用約定就行了。
在了解了函數(shù)調用約定和函數(shù)的名修飾規(guī)則之后，再來看在C++程序中使用C語言編譯的庫時經(jīng)常出現(xiàn)的LNK 2001錯誤就很簡單了。還以上面例子的兩個模塊為例，這一次兩個模塊在編譯的時候都采用__stdcall調用約定，但是a.dll使用C語言的語法編 譯的（C語言方式），所以a.dll的載入庫a.lib中MakeFun函數(shù)的名字修飾就是“_MakeFun@4”。b包含了a提供的頭文件中MakeFun函數(shù)聲明，但是由于b采用的是C++語言編譯，所以MakeFun在b模塊中被按照C++的名字修飾規(guī)則命名為“?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模塊知道這個函數(shù)是C語言編譯的，extern "C"可以做到這一點。一個采用C語言編譯的庫應該考慮到使用這個庫的程序可能是C++程序（使用C++編譯器），所以在設計頭文件時應該注意這一點。通常應該這樣聲明頭文件：
#ifdef _cplusplus
extern "C" {
#endif
long MakeFun(long lFun);
#ifdef _cplusplus
}
#endif
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
這樣C++的編譯器就知道MakeFun的修飾名是“_MakeFun@4”，就不會有鏈接錯誤了。
許多人不明白，為什么我使用的編譯器都是VC的編譯器還會產(chǎn)生“error LNK2001”錯誤？其實，VC的編譯器會根據(jù)源文件的擴展名選擇編譯方式，如果文件的擴展名是“.C”，編譯器會采用C的語法編譯，如果擴展名是 “.cpp”，編譯器會使用C++的語法編譯程序，所以，最好的方法就是使用extern "C"。