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