“C”或者“C++”函數在內部（編譯和鏈接）通過修飾名識別。修飾名是編譯器在編譯函數定義或者原型時生成的字 符串。有些情況下使用函數的修飾名是必要的，如在模塊定義文件裡頭指定輸出“C++”重載函數、構造函數、析構函數，又如在匯編代碼裡調用“C””或“C ++”函數等。
修飾名由函數名、類名、調用約定、返回類型、參數等共同決定。
調用約定
調用約定(Calling convention)決定以下內容：函數參數的壓棧順序，由調用者還是被調用者把參數彈出棧，以及產生函數修飾名的方法。MFC支持以下調用約定：
_cdecl
按從右至左的順序壓參數入棧，由調用者（#add 即函數外部的另一個函數）把參數彈出棧。
對於“C”函數或者變量，修飾名是在函數名前加下劃線。
對於“C++”函數，有所不同。
如函數void test(void)的修飾名是_test；
對於不屬於一個類的“C++”全局函數，修飾名是?test@@ZAXXZ。
這是MFC缺省調用約定。由於是調用者負責把參數彈出棧，所以可以給函數定義個數不定的參數，如printf函數。
_stdcall
按從右至左的順序壓參數入棧，由被調用者（#add 即函數本身）把參數彈出棧。
對於“C”函數或者變量，修飾名以下劃線為前綴，然後是函數名，然後是符號“@”及參數的字節數，如函數int func(int a, double b)的修飾名是_func@12。
對於“C++”函數，則有所不同。
所有的Win32 API函數都遵循該約定。
_fastcall
頭兩個DWORD類型或者占更少字節的參數被放入ECX和EDX寄存器，其他剩下的參數按從右到左的順序壓入棧，由被調用者把參數彈出棧。
對於“C”函數或者變量，修飾名以“@”為前綴，然後是函數名，接著是符號“@”及參數的字節數，如函數int func(int a, double b)的修飾名是@func@12。
對於“C++”函數，有所不同。
未來的編譯器可能使用不同的寄存器來存放參數。
thiscall
僅僅應用於“C++”成員函數。this指針存放於CX寄存器，參數從右到左壓棧。thiscall不是關鍵詞，因此不能被程序員指定。
naked call
采用1-4的調用約定時，如果必要的話，進入函數時編譯器會產生代碼來保存ESI，EDI，EBX，EBP寄存器，退出函數時則產生代碼恢復這些寄存器的內容。naked call不產生這樣的代碼。
naked call不是類型修飾符，故必須和_declspec共同使用，如下：
__declspec( naked ) int func( formal_parameters )
{
// Function body
}
過時的調用約定
原來的一些調用約定可以不再使用。它們被定義成調用約定_stdcall或者_cdecl。例如：
#define CALLBACK __stdcall
#define WINAPI __stdcall
#define WINAPIV __cdecl
#define APIENTRY WINAPI
#define APIPRIVATE __stdcall
#define PASCAL __stdcall
表7-1顯示了一個函數在幾種調用約定下的修飾名（表中的“C++”函數指的是“C++”全局函數，不是成員函數），函數原型是void CALLTYPE test(void)，CALLTYPE可以是_cdecl、_fastcall、_stdcall。
表7-1 不同調用約定下的修飾名
調用約定 extern “C”或.C文件 .cpp, .cxx或/TP編譯開關 _cdecl _test ?test@@ZAXXZ _fastcall @test@0 ?test@@YIXXZ _stdcall _test@0 ?test@@YGXXZ
C++ 編譯器的函數名修飾規則
函數名字修飾（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);
其函數修飾名為“?Function1@@YGHPADK@Z”，
而對於函數聲明：
void Function2();
其函數修飾名則為“?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;
......
};
對於成員函數Function，其函數修飾名為“?Function@CTest@@AAEXH@Z”，字符串“@@AAE”表示這是一個私有函數。
成員函數CopyInfo只有一個參數，是對類CTest的const引用參數，其函數修飾名為“?CopyInfo@CTest@@IAEXABV1@@Z”。（#add 末尾怎麼有兩個@？）
DrawText是一個比較復雜的函數聲明，不僅有字符串參數，還有結構體參數和HDC句柄參數，需要指出的是HDC實際上是一個HDC__結構類型的指針，這個參數的表示就是“PAUHDC__@@”，其完整的函數修飾名為“?DrawText@CTest@@QAEJPAUHDC__@@JPBDUtagRGBQUAD@@E_N@Z”。
InsightClass是一個public 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);
動態庫生成的時候采用的函數調用約定是__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語言編譯的庫時經常出現的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
這樣C++的編譯器就知道MakeFun的修飾名是“_MakeFun@4”，就不會有鏈接錯誤了。
許多人不明白，為什麼我使用的編譯器都是VC的編譯器還會產生“error LNK2001”錯誤？其實，VC的編譯器會根據源文件的擴展名選擇編譯方式，如果文件的擴展名是“.C”，編譯器會采用C的語法編譯，如果擴展名是“.cpp”，編譯器會使用C++的語法編譯程序，所以，最好的方法就是使用extern "C"。
1.__stdcall
以“?”標識函數名的開始，後跟函數名； 函數名後面以“@@YG”標識參數表的開始，後跟參數表；
參數表以代號表示： 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”代表一次重復；
參數表的第一項為該函數的返回值類型，其後依次為參數的數據類型，指針標識在其所指數據類型前；
參數表後以“@Z”標識整個名字的結束，如果該函數無參數，則以“Z”標識結束。 其格式為“?functionname@@YG*****@Z”或“?functionname@@YG*XZ”， 例如 int Test1（char *var1，unsigned long）-----“?Test1@@YGHPADK@Z” void Test2（） -----“?Test2@@YGXXZ”
2 __cdecl調用約定： 規則同上面的 _stdcall 調用約定，只是參數表的開始標識由上面的“@@YG”變為“@@YA”。
3 __fastcall調用約定： 規則同上面的_stdcall調用約定，只是參數表的開始標識由上面的“@@YG”變為“@@YI”。
VC++對函數的省缺聲明是"__cedcl"，將只能被C/C++調用。
CB在輸出函數聲明時使用4種修飾符號 :
__cdecl cb 的默認值，它會在輸出函數名前加 "_"，並保留此函數名不變，參數按照從右到左的順序依次傳遞給棧，也可以寫成_cdecl和cdecl形式。
__fastcall 修飾的函數的參數將盡可能的使用寄存器來處理，其函數名前加@，參數按照從左到右的順序壓棧；
__pascal 它說明的函數名使用 Pascal 格式的命名約定。這時函數名全部大寫。參數按照從左到右的順序壓棧；
__stdcall 使用標准約定的函數名。函數名不會改變。使用 __stdcall 修飾時。參數按照由右到左的順序壓棧，也可以是_stdcall；
C語言函數調用約定
在C語言中，假設我們有這樣的一個函數：
int function(int a,int b)
調用時只要用 result = function(1,2) 這樣的方式就可以使用這個函數。但是，當高級語言被編譯成計算機可以識別的機器碼時，有一個問題就出現來：在CPU中，計算機沒有辦法知道一個函數調用需要多少個、什麼樣的參數，也沒有硬件可以保存這些參數。也就是說，計算機不知道怎麼給這個函數傳遞參數，傳遞參數的工作必須由函數調用者和函數本身來協調。為此，計算機提供了一種被稱為棧的數據結構來支持參數傳遞。
棧是一種先後進先出的數據結構，棧有一個存儲區、一個棧頂指針。棧頂指針指向堆棧中第一個可用的數據項（被稱為棧頂）。用戶可以在棧頂上方向棧中加入數據，這個操作被稱為壓棧 (Push)，壓棧以後，棧頂自動變成新加入數據項的位置，棧頂指針也隨之修改。用戶也可以從堆棧中取走棧頂，稱為彈出棧 (pop)，彈出棧後，棧頂下的一個元素變成棧頂，棧頂指針隨之修改。
函數調用時，調用者依次把參數壓棧，然後調用函數，函數被調用以後，在堆棧中取得數據，並進行計算。函數計算結束以後，或者調用者、或者函數本身修改堆棧，使堆棧恢復原裝。
在參數傳遞中，有兩個很重要的問題必須得到明確說明：
當參數個數多於一個時，按照什麼順序把參數壓入堆棧
函數調用後，由誰來把堆棧恢復原狀
在高級語言中，通過函數調用約定來說明這兩個問題。常見的調用約定有：
stdcall
cdecl
fastcall
thiscall
naked call
stdcall調用約定
stdcall很多時候被稱為pascal調用約定，因為pascal是早期很常見的一種教學用計算機程序設計語言，其語法嚴謹，使用的函數調用約定就是stdcall。在Microsoft C++系列的C/C++編譯器中，常常用PASCAL宏來聲明這個調用約定，類似的宏還有WINAPI和CALLBACK。
stdcall調用約定聲明的語法為(以前文的那個函數為例）：
int __stdcall function(int a,int b)
stdcall的調用約定意味著：1）參數從右向左壓入堆棧，2）函數自身修改堆棧 3)函數名自動加前導的下劃線，後面緊跟一個@符號，其後緊跟著參數的尺寸
以上述這個函數為例，參數b首先被壓棧，然後是參數a，函數調用function(1,2)調用處翻譯成匯編語言將變成：
push 2 // 第二個參數入棧
push 1 // 第一個參數入棧
call function // 調用參數，注意此時自動把cs:eip入棧
而對於函數自身，則可以翻譯為：
push ebp // 保存ebp寄存器，該寄存器將用來保存堆棧的棧頂指針，可以在函數退出時恢復
mov ebp,esp // 保存堆棧指針
mov eax,[ebp + 8H] // 堆棧中ebp指向位置之前依次保存有 ebp,cs:eip,a,b,ebp + 8指向 a
add eax,[ebp + 0CH] // 堆棧中ebp + 1 2處保存了b
mov esp,ebp // 恢復esp
pop ebp
ret 8
而在編譯時，這個函數的名字被翻譯成_function@8
注意不同編譯器會插入自己的匯編代碼以提供編譯的通用性，但是大體代碼如此。
其中在函數開始處保留esp到ebp中，在函數結束恢復是編譯器常用的方法。
從函數調用看，2和1依次被push進堆棧，而在函數中又通過相對於ebp(即剛進函數時的堆棧指針）的偏移量存取參數。
函數結束後，ret 8 表示清理8個字節的堆棧，函數自己恢復了堆棧。
cdecl調用約定
cdecl 調用約定又稱為C調用約定，是C語言缺省的調用約定，它的定義語法是：
int function (int a ,int b) //不加修飾就是C調用約定
int __cdecl function(int a,int b) //明確指出C調用約定
cdecl調用約定的參數壓棧順序是和 stdcall是一樣的，參數首先由有向左壓入堆棧。
所不同的是，函數本身不清理堆棧，調用者負責清理堆棧。
由於這種變化，C 調用約定允許函數的參數的個數是不固定的，這也是C語言的一大特色。
對於前面的function函數，使用cdecl後的匯編碼變成：
調用處
push 1
push 2
call functionadd
esp,8 // 注意：這裡調用者在恢復堆棧
被調用函數_function處
push ebp // 保存ebp寄存器，該寄存器將用來保存堆棧的棧頂指針，可以在函數退出時恢復
mov ebp,esp // 保存堆棧指針
mov eax,[ebp + 8H] // 堆棧中ebp指向位置之前依次保存有 ebp, cs:eip,a,b,ebp +8指向a
add eax,[ebp + 0CH] // 堆棧中ebp + 12處保存了b
mov esp,ebp // 恢復esp
pop ebp
ret // 注意，這裡沒有修改堆棧
MSDN中說，該修飾自動在函數名前加前導的下劃線，因此函數名在符號表中被記錄為_function，但是我在編譯時似乎沒有看到這種變化。
由於參數按照從右向左順序壓棧，因此最開始的參數在最接近棧頂的位置，因此當采用不定個數參數時，第一個參數在棧中的位置肯定能知道，只要不定的參數個數能夠根據第一個後者後續的明確的參數確定下來，就可以使用不定參數，例如對於CRT中的sprintf函數，定義為：
int sprintf(char* buffer,const char* format,...)
由於所有的不定參數都可以通過 format 確定，因此使用不定個數的參數是沒有問題的。
fastcall調用約定
fastcall調用約定和stdcall類似，它意味著：
函數的第一個和第二個DWORD參數（或者尺寸更小的）通過ecx和edx傳遞，其他參數通過從右向左的順序壓棧
被調用函數清理堆棧
函數名修改規則同stdcall
其聲明語法為：int fastcall function(int a,int b)
為了說明這個調用約定，定義如下類和使用代碼：
class A
{
public:
int function1(int a,int b);
int function2(int a,...);
};
int A::function1 (int a,int b)
{
return a+b;
}
int A::function2(int a,...)
{
va_list ap;
va_start(ap,a);
int i;
int result = 0;
for(i = 0 ; i < a ; i ++)
{
result += va_arg(ap,int);
}
return result;
}
void callee()
{
A a;
a.function1 (1,2);
a.function2(3,1,2,3);
}
// 下面這段匯編代碼是原文章的，我覺得有問題，還是自己反匯編看看
//函數function1調用0401C1D
push 200401C1F
push 100401C21
lea ecx,[ebp-8]00401C24
call function1
// 注意，這裡this沒有被入棧
//函數function2調用00401C29
push 300401C2B
push 200401C2D
push 100401C2F
push 300401C31
lea eax,[ebp-8]
這裡引入this指針00401C34
push eax00401C35
call function200401C3A
add esp,14h
以下代碼是我修改分析的：
上面的C++代碼，必須包含 stdarg.h ，提供動態參數頭文件
int A::function1 (int a,int b) //
{
004113A0 push ebp
004113A1 mov ebp,esp
004113A3 sub esp,0CCh
004113A9 push ebx
004113AA push esi
004113AB push edi
004113AC push ecx
004113AD lea edi,[ebp-0CCh]
004113B3 mov ecx,33h
004113B8 mov eax,0CCCCCCCCh
004113BD rep stos dword ptr es:[edi]
004113BF pop ecx
004113C0 mov dword ptr [ebp-8],ecx
return a+b;
004113C3 mov eax,dword ptr [a]
004113C6 add eax,dword ptr [b]
}
004113C9 pop edi
004113CA pop esi
004113CB pop ebx
004113CC mov esp,ebp
004113CE pop ebp
004113CF ret 8
void callee()
{
00411460 push ebp
00411461 mov ebp,esp
00411463 sub esp,0CCh
00411469 push ebx
0041146A push esi
0041146B push edi
0041146C lea edi,[ebp-0CCh]
00411472 mov ecx,33h
00411477 mov eax,0CCCCCCCCh
0041147C rep stos dword ptr es:[edi]
A a;
a.function1 (1,2);
0041147E push 2 // 參數 2 入棧
00411480 push 1 // 參數 1 入棧
00411482 lea ecx,[a] // this 指針 ----> ECX
00411485 call A::function1 (411050h)
a.function2(3,1,2,3);
0041148A push 3
0041148C push 2
0041148E push 1
00411490 push 3
00411492 lea eax,[a] // 這裡 this 指針入棧了，對照 callee 對 function1 的調用，
00411495 push eax // 對 this 的處理是不同的
00411496 call A::function2 (411122h) // 此處調用者自己沒有恢復堆棧
// 由於上面的入棧順序可知，在 function 2中 當保存ebp 後(打開stack frame後)，堆棧的狀態如下.
ebp // 保存的 EBP 的值, 且 此時ebp指向該處
RetAddr // 返回地址
this指針 // 入棧的 this 指針
參數 3 // 下面是入棧的參數, 從右向左入棧
參數 1
參數 2
參數 3
0041149B add esp,14h // 此處調用者自己恢復堆棧
//.............下面的匯編代碼是 檢查堆棧和恢復 callee 堆棧的操作，不再寫了
}
可見，對於參數個數固定情況下，它類似於stdcall，不定時則類似cdecl
naked call 調用約定
這是一個很少見的調用約定，一般程序設計者建議不要使用。編譯器不會給這種函數增加初始化和清理代碼，更特殊的是，你不能用return返
回返回值，只能用插入匯編返回結果。這一般用於實模式驅動程序設計，假設定義一個求和的加法程序，可以定義為：
__declspec(naked) int add(int a,int b)
{
__asm mov eax,a
__asm add eax,b
__asm ret
}
注意，這個函數沒有顯式的return返回值，返回通過修改eax寄存器實現，而且連退出函數的ret指令都必須顯式插入。
上面代碼被翻譯成匯編以後變成：
mov eax,[ebp+8]
add eax,[ebp+12]
ret 8
注意這個修飾是和__stdcall及cdecl結合使用的，前面是它和cdecl結合使用的代碼，對於和stdcall結合的代碼，則變成：
__declspec(naked) int __stdcall function(int a,int b)
{
__asm mov eax,a
__asm add eax,b
__asm ret 8 //注意後面的8
}
至於這種函數被調用，則和普通的cdecl及stdcall調用函數一致。
函數調用約定導致的常見問題
如果定義的約定和使用的約定不一致，則將導致堆棧被破壞，導致嚴重問題，下面是兩種常見的問題：
函數原型聲明和函數體定義不一致
DLL導入函數時聲明了不同的函數約定
以後者為例，假設我們在dll種聲明了一種函數為：
__declspec(dllexport) int func(int a,int b);//注意，這裡沒有stdcall，使用的是cdecl
使用時代碼為：
typedef int (*WINAPI DLLFUNC)func(int a,int b);
hLib = LoadLibrary(...);
DLLFUNC func = (DLLFUNC)GetProcAddress(...) //這裡修改了調用約定
result = func(1,2); //導致錯誤
由於調用者沒有理解WINAPI的含義錯誤的增加了這個修飾，上述代碼必然導致堆棧被破壞，
MFC在編譯時插入的checkesp函數將告訴你，堆棧被破壞了。
摘自 踏雪無痕
