唯C主義

    使用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);

其函數修飾名為“?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”。 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);

動態庫生成的時候采用的函數調用約定是__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

這樣C++的編譯器就知道MakeFun的修飾名是“_MakeFun@4”，就不會有鏈接錯誤了。

    許多人不明白，為什么我使用的編譯器都是VC的編譯器還會產生“error LNK2001”錯誤？其實，VC的編譯器會根據源文件的擴展名選擇編譯方式，如果文件的擴展名是“.C”，編譯器會采用C的語法編譯，如果擴展名是 “.cpp”，編譯器會使用C++的語法編譯程序，所以，最好的方法就是使用extern "C"。

 

1. ASCII碼

我們知道，在計算機內部，所有的信息最終都表示為一個二進制的字符串。每一個二進制位（bit）有0和1兩種狀態，因此八個二進制位就可以組合出 256種狀態，這被稱為一個字節（byte）。也就是說，一個字節一共可以用來表示256種不同的狀態，每一個狀態對應一個符號，就是256個符號，從 0000000到11111111。

上個世紀60年代，美國制定了一套字符編碼，對英語字符與二進制位之間的關系，做了統一規定。這被稱為ASCII碼，一直沿用至今。

ASCII碼一共規定了128個字符的編碼，比如空格“SPACE”是32（二進制00100000），大寫的字母A是65（二進制01000001）。這128個符號（包括32個不能打印出來的控制符號），只占用了一個字節的后面7位，最前面的1位統一規定為0。

2、非ASCII編碼

英語用128個符號編碼就夠了，但是用來表示其他語言，128個符號是不夠的。比如，在法語中，字母上方有注音符號，它就無法用ASCII碼表示。 于是，一些歐洲國家就決定，利用字節中閑置的最高位編入新的符號。比如，法語中的é的編碼為130（二進制10000010）。這樣一來，這些歐洲國家使 用的編碼體系，可以表示最多256個符號。

但是，這里又出現了新的問題。不同的國家有不同的字母，因此，哪怕它們都使用256個符號的編碼方式，代表的字母卻不一樣。比如，130在法語編碼 中代表了é，在希伯來語編碼中卻代表了字母Gimel (?)，在俄語編碼中又會代表另一個符號。但是不管怎樣，所有這些編碼方式中，0—127表示的符號是一樣的，不一樣的只是128—255的這一段。

至于亞洲國家的文字，使用的符號就更多了，漢字就多達10萬左右。一個字節只能表示256種符號，肯定是不夠的，就必須使用多個字節表達一個符號。 比如，簡體中文常見的編碼方式是GB2312，使用兩個字節表示一個漢字，所以理論上最多可以表示256x256=65536個符號。

中文編碼的問題需要專文討論，這篇筆記不涉及。這里只指出，雖然都是用多個字節表示一個符號，但是GB類的漢字編碼與后文的Unicode和UTF-8是毫無關系的。

3.Unicode

正如上一節所說，世界上存在著多種編碼方式，同一個二進制數字可以被解釋成不同的符號。因此，要想打開一個文本文件，就必須知道它的編碼方式，否則用錯誤的編碼方式解讀，就會出現亂碼。為什么電子郵件常常出現亂碼？就是因為發信人和收信人使用的編碼方式不一樣。

可以想象，如果有一種編碼，將世界上所有的符號都納入其中。每一個符號都給予一個獨一無二的編碼，那么亂碼問題就會消失。這就是Unicode，就像它的名字都表示的，這是一種所有符號的編碼。

Unicode當然是一個很大的集合，現在的規?？梢匀菁{100多萬個符號。每個符號的編碼都不一樣，比如，U+0639表示阿拉伯字母Ain，U+0041表示英語的大寫字母A，U+4E25表示漢字“嚴”。具體的符號對應表，可以查詢unicode.org，或者專門的漢字對應表。

4. Unicode的問題

需要注意的是，Unicode只是一個符號集，它只規定了符號的二進制代碼，卻沒有規定這個二進制代碼應該如何存儲。

比如，漢字“嚴”的unicode是十六進制數4E25，轉換成二進制數足足有15位（100111000100101），也就是說這個符號的表示至少需要2個字節。表示其他更大的符號，可能需要3個字節或者4個字節，甚至更多。

這里就有兩個嚴重的問題，第一個問題是，如何才能區別unicode和ascii？計算機怎么知道三個字節表示一個符號，而不是分別表示三個符號 呢？第二個問題是，我們已經知道，英文字母只用一個字節表示就夠了，如果unicode統一規定，每個符號用三個或四個字節表示，那么每個英文字母前都必 然有二到三個字節是0，這對于存儲來說是極大的浪費，文本文件的大小會因此大出二三倍，這是無法接受的。

它們造成的結果是：1）出現了unicode的多種存儲方式，也就是說有許多種不同的二進制格式，可以用來表示unicode。2）unicode在很長一段時間內無法推廣，直到互聯網的出現。

5.UTF-8

互聯網的普及，強烈要求出現一種統一的編碼方式。UTF-8就是在互聯網上使用最廣的一種unicode的實現方式。其他實現方式還包括UTF-16和UTF-32，不過在互聯網上基本不用。重復一遍，這里的關系是，UTF-8是Unicode的實現方式之一。

UTF-8最大的一個特點，就是它是一種變長的編碼方式。它可以使用1~4個字節表示一個符號，根據不同的符號而變化字節長度。

UTF-8的編碼規則很簡單，只有二條：

1）對于單字節的符號，字節的第一位設為0，后面7位為這個符號的unicode碼。因此對于英語字母，UTF-8編碼和ASCII碼是相同的。

2）對于n字節的符號（n>1），第一個字節的前n位都設為1，第n+1位設為0，后面字節的前兩位一律設為10。剩下的沒有提及的二進制位，全部為這個符號的unicode碼。

下表總結了編碼規則，字母x表示可用編碼的位。

Unicode符號范圍 | UTF-8編碼方式
(十六進制) | （二進制）
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

下面，還是以漢字“嚴”為例，演示如何實現UTF-8編碼。

已知“嚴”的unicode是4E25（100111000100101），根據上表，可以發現4E25處在第三行的范圍內（0000 0800-0000 FFFF），因此“嚴”的UTF-8編碼需要三個字節，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，從“嚴”的最后一個二進制位開始，依次從后向前填入格式中的x，多出的位補0。這樣就得到了，“嚴”的UTF-8編碼是 “11100100 10111000 10100101”，轉換成十六進制就是E4B8A5。

6. Unicode與UTF-8之間的轉換

通過上一節的例子，可以看到“嚴”的Unicode碼是4E25，UTF-8編碼是E4B8A5，兩者是不一樣的。它們之間的轉換可以通過程序實現。

在Windows平臺下，有一個最簡單的轉化方法，就是使用內置的記事本小程序Notepad.exe。打開文件后，點擊“文件”菜單中的“另存為”命令，會跳出一個對話框，在最底部有一個“編碼”的下拉條。

里面有四個選項：ANSI，Unicode，Unicode big endian 和 UTF-8。

1）ANSI是默認的編碼方式。對于英文文件是ASCII編碼，對于簡體中文文件是GB2312編碼（只針對Windows簡體中文版，如果是繁體中文版會采用Big5碼）。

2）Unicode編碼指的是UCS-2編碼方式，即直接用兩個字節存入字符的Unicode碼。這個選項用的little endian格式。

3）Unicode big endian編碼與上一個選項相對應。我在下一節會解釋little endian和big endian的涵義。

4）UTF-8編碼，也就是上一節談到的編碼方法。

選擇完”編碼方式“后，點擊”保存“按鈕，文件的編碼方式就立刻轉換好了。

7. Little endian和Big endian

上一節已經提到，Unicode碼可以采用UCS-2格式直接存儲。以漢字”嚴“為例，Unicode碼是4E25，需要用兩個字節存儲，一個字節 是4E，另一個字節是25。存儲的時候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。

這兩個古怪的名稱來自英國作家斯威夫特的《格列佛游記》。在該書中，小人國里爆發了內戰，戰爭起因是人們爭論，吃雞蛋時究竟是從大頭(Big- Endian)敲開還是從小頭(Little-Endian)敲開。為了這件事情，前后爆發了六次戰爭，一個皇帝送了命，另一個皇帝丟了王位。

因此，第一個字節在前，就是”大頭方式“（Big endian），第二個字節在前就是”小頭方式“（Little endian）。

那么很自然的，就會出現一個問題：計算機怎么知道某一個文件到底采用哪一種方式編碼？

Unicode規范中定義，每一個文件的最前面分別加入一個表示編碼順序的字符，這個字符的名字叫做”零寬度非換行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。這正好是兩個字節，而且FF比FE大1。

如果一個文本文件的頭兩個字節是FE FF，就表示該文件采用大頭方式；如果頭兩個字節是FF FE，就表示該文件采用小頭方式。

8. 實例

下面，舉一個實例。

打開”記事本“程序Notepad.exe，新建一個文本文件，內容就是一個”嚴“字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8編碼方式保存。

然后，用文本編輯軟件UltraEdit中的”十六進制功能“，觀察該文件的內部編碼方式。

1）ANSI：文件的編碼就是兩個字節“D1 CF”，這正是“嚴”的GB2312編碼，這也暗示GB2312是采用大頭方式存儲的。

2）Unicode：編碼是四個字節“FF FE 25 4E”，其中“FF FE”表明是小頭方式存儲，真正的編碼是4E25。

3）Unicode big endian：編碼是四個字節“FE FF 4E 25”，其中“FE FF”表明是大頭方式存儲。

4）UTF-8：編碼是六個字節“EF BB BF E4 B8 A5”，前三個字節“EF BB BF”表示這是UTF-8編碼，后三個“E4B8A5”就是“嚴”的具體編碼，它的存儲順序與編碼順序是一致的。

9. 延伸閱讀

* The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets（關于字符集的最基本知識）

* 談談Unicode編碼

* RFC3629：UTF-8, a transformation format of ISO 10646（如果實現UTF-8的規定）

如果你用C++來編寫COM，那么你將必不可少的使用這三個類型。使用這三種wrapper class毫無疑問會簡化我們的編程，使得使用SAFEARRAY, VARIANT和BSTR簡單。但是，使用這三個類型依然需要小心，因為使用不當的話，就會造成內存泄漏，或效率降低。

1. 如果拷貝兩個BSTR
假如我們一個BSTR，這個時候我希望復制一份BSTR，并丟棄之前的BSTR。通常我們會這么寫：

當然，上面這個程序沒有任何問題，不會有任何內存泄漏的可能。但是，你有沒有上面代碼里都發生了什么了？
答案很簡單，在函數StringToBSTR里面，講bstrValue返回的時候，會調用CComBSTR::Copy()，在Copy()里面將會調用
 ::SysAllocStringByteLen()
這個函數。而后在給vValue賦值的時候，又 會調用一次
::SysAllocString()
顯而易見，開銷很大。

那么，我們將怎么改進這段代碼了？
這樣，通過CComBSTR::Detach()，我們將BSTR返回回來，通過CComBSTR::Attach()，我們將BSTR指針存儲起來。這樣，就減小了兩次開銷，大大提高了效率，也不會造成內存效率。

2. 如何使用CComSafeArray
使 用CComSafeArray的一個最大的好處，就是它會自動釋放元素是VARIANT和BSTR。也就是說，如果你的類型是VARIANT，它會自動調 用::VariantClear()。如果你的類型是BSTR，他會自動調用::SysStringFree()方法。但是使用它的時候，同樣要小心。
2.1 成對使用::SafeArrayAccessData()和::SafeArrayUnaccessData()
我們有時候會這樣使用CComSafeArray的元素：
因為::SafeArrayAccessData 方法會在SFAEARRAY上給lock加1. 如果上面程序顯示調用CComSafeArray::Destroy()函數，你檢查它返回來的HRESULT的時候，應該是下面的值：
        hr    0x8002000d 內存已鎖定。     HRESULT
如果你不仔細檢查，那么將造成CComSafeArray沒有釋放。
2.2 從CComSafeArray轉為成CComVariant
有時候我們使用CComVariant包裝SAFEARRY。你會這樣寫代碼：
你可能會任務CComVariant會存儲pSafeArray的指針?？上?，你錯了。
CComVariant會調用::SafeArrayCopy 來完成賦值操作。而你的pSafeArray已經調用了Detach()操作，那么它里面的SAFEARRAY就變成了孤兒，沒有人去釋放它了。
那么你應該怎么寫了？
你可以這么寫：
這樣，CComVariant會調用::SafeArrayCopy 來完成復制操作，而CComSafeArray也會保證在析構的時候釋放里面的SAFEARRAY。

使用上面三個wrapper類，確實可以很方便我們編程，也能避免很多memory leak。但是，使用他們同樣要小心，不然，同樣會造成性能損失，或者，更糟糕的，內存泄漏。

一 static 產生背景

引出原因：函數內部定義的變量，在程序執行到它的定義處時，編譯器為它在棧上分配空間，大家知道，函數

在棧上分配的空間在此函數執行結束時會釋放掉，這樣就產生了一個問題: 如果想將函數中此變量的值保存至

下一次調用時，如何實現？

最容易想到的方法是定義一個全局的變量，但定義為一個全局變量有許多缺點，最明顯的缺點是破壞了此變量

的訪問范圍（使得在此函數中定義的變量，不僅僅受此函數控制）。

       類的靜態成員也是這個道理。


解決方案：因此C++ 中引入了static，用它來修飾變量，它能夠指示編譯

器將此變量在程序的靜態存儲區分配空間保存，這樣即實現了目的，又使得此變量的存取范圍不變。


2) 具體作用

Static作用分析總結：static總是使得變量或對象的存儲形式變成靜態存儲，連接方式變成內部連接，對于局

部變量（已經是內部連接了），它僅改變其存儲方式；對于全局變量（已經是靜態存儲了），它僅改變其連接

類型。(1 連接方式：成為內部連接；2 存儲形式：存放在靜態全局存儲區)
二 const 產生背景

a) C++有一個類型嚴格的編譯系統，這使得C++程序的錯誤在編譯階段即可發現許多，從而使得出錯率大為減少

，因此，也成為了C++與C相比，有著突出優點的一個方面。

b) C中很常見的預處理指令 #define VariableName VariableValue 可以很方便地進行值替代，這種值替代至

少在三個方面優點突出：

一是避免了意義模糊的數字出現，使得程序語義流暢清晰，如下例：

　　#define USER_NUM_MAX 107 這樣就避免了直接使用107帶來的困惑。

二是可以很方便地進行參數的調整與修改，如上例，當人數由107變為201時，改動此處即可；

三是提高了程序的執行效率，由于使用了預編譯器進行值替代，并不需要為這些常量分配存儲空間，所以執行

的效率較高。

然而，預處理語句雖然有以上的許多優點，但它有個比較致命的缺點，即，預處理語
句僅僅只是簡單值替代，缺乏類型的檢測機制。這樣預處理語句就不能享受C++嚴
格類型檢查的好處，從而可能成為引發一系列錯誤的隱患。


Const 推出的初始目的，正是為了取代預編譯指令，消除它的缺點，同時

繼承它的優點。

現在它的形式變成了：

Const DataType VariableName = VariableValue ;

2) 具體作用

1.const 用于指針的兩種情況分析：

　
int const *A; 　//A可變，*A不可變

　
int *const A; 　//A不可變，*A可變

　分析：const 是一個左結合的類型修飾符，它與其左側的類型修飾符和為一個

類型修飾符，所以，int const 限定 *A,不限定A。int *const 限定A,不限定*A。


2.const 限定函數的傳遞值參數：

　
void Fun(const int Var);
　    分析：上述寫法限定參數在函數體中不可被改變。


3.const 限定函數的值型返回值：

const int Fun1();
const MyClass Fun2();
　    分析:上述寫法限定函數的返回值不可被更新，當函數返回內部的類型時（如Fun1），已經是一個數值，

當然不可被賦值更新，所以，此時const無意義，最好去掉，以免困惑。當函數返回自定義的類型時（如Fun2）

，這個類型仍然包含可以被賦值的變量成員，所以，此時有意義。


4. 傳遞與返回地址： 此種情況最為常見，由地址變量的特點可知，適當使用const，意義昭然。


5.　const 限定類的成員函數：

class ClassName {
　public:
　　int Fun() const;
　.....
}
　　注意：采用此種const 后置的形式是一種規定，亦為了不引起混淆。在此函數的聲明中和定義中均要使用

const,因為const已經成為類型信息的一部分。

獲得能力：可以操作常量對象。

失去能力：不能修改類的數據成員，不能在函數中調用其他不是const的函數。

三 inline 產生背景

inline這個關鍵字的引入原因和const十分相似，inline 關鍵字用來定義一個類的內聯函數，引入它的主要原

因是用它替代C中

表達式形式的宏定義。

表達式形式的宏定義一例：

　　　#define ExpressionName(Var1,Var2) (Var1+Var2)*(Var1-Var2)
       這種表達式形式宏形式與作用跟函數類似，但它使用預編譯器，沒有堆棧，使用上比函數高效。但它只

是預編譯器上符號表的簡單替換，不能進行參數有效性檢測及使用C++類的成員訪問控制。

inline 推出的目的，也正是為了取代這種表達式形式的宏定義，它消除了它的缺點，同時又很好地繼承了它的

優點。inline代碼放入預編譯器符號表中，高效；它是個真正的函數，調用時有嚴格的參數檢測；它也可作為

類的成員函數。


2) 具體作用

直接在class類定義中定義各函數成員，系統將他們作為內聯函數處理； 成員函數是內聯函數，意味著：每個

對象都有該函數一份獨立的拷貝。
在類外，如果使用關鍵字inline定義函數成員，則系統也會作為內聯函數處理；

C關鍵字
#define 宏名
要替換的代碼

宏定義，保存在預編譯器的符號表中，執行高效；作為一種簡單的符號替換，不進行其中參數有效性的檢測


typedef
已有類型
新類型

別名,
常用于創建平臺無關類型, typedef 在編譯時被解釋，因此讓編譯器來應付超越預處理器能力的文本替換。

C 風格（C-style）強制轉型如下：
(T) exdivssion // cast exdivssion to be of type T
函數風格（Function-style）強制轉型使用這樣的語法：
T(exdivssion) // cast exdivssion to be of type T

這兩種形式之間沒有本質上的不同，它純粹就是一個把括號放在哪的問題。我把這兩種形式稱為舊風格（old-style）的強制轉型。


使用標準C++的類型轉換符：static_cast、dynamic_cast、reinterdivt_cast、和const_cast。
1. static_cast
用法：static_cast < type-id > ( exdivssion )
該運算符把exdivssion轉換為type-id類型，但沒有運行時類型檢查來保證轉換的安全性。它主要有如下幾種用法：
①用于類層次結構中基類和子類之間指針或引用的轉換。
　　進行上行轉換（把子類的指針或引用轉換成基類表示）是安全的；
　　進行下行轉換（把基類指針或引用轉換成子類表示）時，由于沒有動態類型檢查，所以是不安全的。
②用于基本數據類型之間的轉換，如把int轉換成char，把int轉換成enum。這種轉換的安全性也要開發人員來保證。
③把空指針轉換成目標類型的空指針。
④把任何類型的表達式轉換成void類型。
注意：static_cast不能轉換掉exdivssion的const、volitale、或者__unaligned屬性。

2. dynamic_cast
用法：dynamic_cast < type-id > ( exdivssion )
該運算符把exdivssion轉換成type-id類型的對象。Type-id必須是類的指針、類的引用或者void *；
如果type-id是類指針類型，那么exdivssion也必須是一個指針，如果type-id是一個引用，那么exdivssion也必須是一個引用。
dynamic_cast主要用于類層次間的上行轉換和下行轉換，還可以用于類之間的交叉轉換。
在類層次間進行上行轉換時，dynamic_cast和static_cast的效果是一樣的；
在進行下行轉換時，dynamic_cast具有類型檢查的功能，比static_cast更安全。
class B{
public:
int m_iNum;
virtual void foo();
};
class D:public B{
public:
char *m_szName[100];
};
void func(B *pb){
D *pd1 = static_cast(pb);
D *pd2 = dynamic_cast(pb);
}
在上面的代碼段中，如果pb指向一個D類型的對象，pd1和pd2是一樣的，并且對這兩個指針執行D類型的任何操作都是安全的；
但是，如果pb指向的是一個B類型的對象，那么pd1將是一個指向該對象的指針，對它進行D類型的操作將是不安全的（如訪問m_szName），
而pd2將是一個空指針。
另外要注意：B要有虛函數，否則會編譯出錯；static_cast則沒有這個限制。
這是由于運行時類型檢查需要運行時類型信息，而這個信息存儲在類的虛函數表（
關于虛函數表的概念，詳細可見）中，只有定義了虛函數的類才有虛函數表，
沒有定義虛函數的類是沒有虛函數表的。
另外，dynamic_cast還支持交叉轉換（cross cast）。如下代碼所示。
class A{
public:
int m_iNum;
virtual void f(){}
};
class B:public A{
};
class D:public A{
};
void foo(){
B *pb = new B;
pb->m_iNum = 100;
D *pd1 = static_cast(pb); //compile error
D *pd2 = dynamic_cast(pb); //pd2 is NULL
delete pb;
}
在函數foo中，使用static_cast進行轉換是不被允許的，將在編譯時出錯；而使用 dynamic_cast的轉換則是允許的，結果是空指針。

3. reindivter_cast
用法：reindivter_cast (exdivssion)
type-id必須是一個指針、引用、算術類型、函數指針或者成員指針。
它可以把一個指針轉換成一個整數，也可以把一個整數轉換成一個指針（先把一個指針轉換成一個整數，
在把該整數轉換成原類型的指針，還可以得到原先的指針值）。
該運算符的用法比較多。
4. const_cast
用法：const_cast (exdivssion)
該運算符用來修改類型的const或volatile屬性。除了const 或volatile修飾之外， type_id和exdivssion的類型是一樣的。
常量指針被轉化成非常量指針，并且仍然指向原來的對象；
常量引用被轉換成非常量引用，并且仍然指向原來的對象；常量對象被轉換成非常量對象。
Voiatile和const類試。舉如下一例：
class B{
public:
int m_iNum;
}
void foo(){
const B b1;
b1.m_iNum = 100; //comile error
B b2 = const_cast(b1);
b2. m_iNum = 200; //fine
}
上面的代碼編譯時會報錯，因為b1是一個常量對象，不能對它進行改變；
使用const_cast把它轉換成一個常量對象，就可以對它的數據成員任意改變。注意：b1和b2是兩個不同的對象。

== ===========================================
== dynamic_cast .vs. static_cast
== ===========================================

class B { ... };
class D : public B { ... };

void f(B* pb)
{
D* pd1 = dynamic_cast(pb);
D* pd2 = static_cast(pb);
}


If pb really points to an object of type D, then pd1 and pd2 will get the same value. They will also get the same value if pb == 0.


If pb points to an object of type B and not to the complete D class, then dynamic_cast will know enough to return zero. However, static_cast relies on the programmer’s assertion that pb points to an object of type D and simply returns a pointer to that supposed D object.


即dynamic_cast可用于繼承體系中的向下轉型，即將基類指針轉換為派生類指針，比static_cast更嚴格更安全。dynamic_cast在執行效率上比static_cast要差一些，但static_cast在更寬上范圍內可以完成映射，這種不加限制的映射伴隨著不安全性。static_cast覆蓋的變換類型除類層次的靜態導航以外，還包括無映射變換、窄化變換(這種變換會導致對象切片,丟失信息)、用VOID*的強制變換、隱式類型變換等...


== ===========================================
== static_cast .vs. reinterdivt_cast
== ================================================


reinterdivt_cast是為了映射到一個完全不同類型的意思，這個關鍵詞在我們需要把類型映射回原有類型時用到它。我們映射到的類型僅僅是為了故弄玄虛和其他目的，這是所有映射中最危險的。(這句話是C++編程思想中的原話)
static_cast 和 reinterdivt_cast 操作符修改了操作數類型。它們不是互逆的； static_cast 在編譯時使用類型信息執行轉換，在轉換執行必要的檢測(諸如指針越界計算, 類型檢查). 其操作數相對是安全的。另一方面；reinterdivt_cast 僅僅是重新解釋了給出的對象的比特模型而沒有進行二進制轉換， 例子如下：


int n=9; double d=static_cast < double > (n);


上面的例子中, 我們將一個變量從 int 轉換到 double。 這些類型的二進制表達式是不同的。 要將整數 9 轉換到 雙精度整數 9，static_cast 需要正確地為雙精度整數 d 補足比特位。其結果為 9.0。而reinterdivt_cast 的行為卻不同:


int n=9;
double d=reinterdivt_cast (n);

這次, 結果有所不同. 在進行計算以后, d 包含無用值. 這是因為 reinterdivt_cast 僅僅是復制 n 的比特位到 d, 沒有進行必要的分析.


因此, 你需要謹慎使用 reinterdivt_cast.