CString

CString對象可以被認為是字元數組。將CString看作實際的字元串，而不是指向字元串的指針。

介紹

CString只有一個數據成員m_pszData，值為字元串的首地址，數據類型為wchar_t*或char*。在m_pszData的前面實際還分配了CSringData數據塊，包含了IAtlStringMgr* pStringMgr; int nDataLength; int nAllocLength; int nRefs等管理數據。每次為CString動態分配地址空間，實際分配長度為:(nChars+1)*nCharSize+sizeof(CStringData)。當執行CString的默認構造函數生成一個空串時，實際上都是構造一個CnilStringData對象。

部分編譯器對std::string放棄了寫時複製（Copy On Write）機制。但是，CString一直採取這一機制。GetString方法返回的是只讀的字元串地址；而GetBuffer方法返回的是可寫的字元串地址，如果修改了字元串內容，這時需要調用ReleaseBuffer方法把新的字元串長度修改到元數據中。

CString對象用作可變參數函數（如printf）的實參時，由於無法通過形參類型確定調用哪個CString的類型轉換操作符函數，因此有必要顯式指明要轉換的類型。如果需要在函數的參數傳遞CString，由於CString使用了引用計數，因此函數參數傳遞一個CString對象是可行的；需要修改其內容時，推薦使用const CString&。

前言

CString位於頭文件afx.h中。

這篇文章就來討論這些技巧。

使用CString可以讓你對字元串的操作更加直截了當。這篇文章不是CString的完全手冊，但囊括了大部分常見基本問題。

這篇文章包括以下內容：

CString 對象的連接

格式化字元串（包括 int 型轉化為 CString）

CString類的成員函數

CString 型轉化成 int 型

CString 型和 char* 類型的相互轉化

char* 轉化成 CString

CString 轉化成 char* 之一：使用LPCTSTR強制轉化

CString 轉化成 char* 之二：使用CString對象的GetBuffer方法

CString 轉化成 char* 之三: 和控制項的介面

CString 型轉化成BSTR型；

BSTR 型轉化成 CString 型；

VARIANT型轉化成 CString 型；

載入字元串表資源；

CString 和臨時對象；

CString 的效率；

對象連接

能體現出 CString 類型方便性特點的一個方面就是字元串的連接，使用 CString 類型，你能很方便地連接兩個字元串，正如下面的例子：

要比用下面的方法好得多：

字元串

與其用 sprintf() 函數或 wsprintf() 函數來格式化一個字元串，還不如用 CString 對象的Format()方法：

CString s;

s.Format(_T("The total is %d"),total);

用這種方法的好處是你不用擔心用來存放格式化后數據的緩衝區是否足夠大，這些工作由CString類替你完成。

格式化是一種把其它不是字元串類型的數據轉化為CString類型的最常用技巧，比如，把一個整數轉化成CString類型，可用如下方法：

CString s;

s.Format(_T("%d"),total);

我總是對我的字元串使用_T()宏，這是為了讓我的代碼至少有Unicode的意識，當然，關於Unicode的話題不在這篇文章的討論範圍。_T()宏在8位字元環境下是如下定義的：

#define _T(x) x // 非Unicode版本（non-Unicode version）

而在Unicode環境下是如下定義的：

#define _T(x) L##x // Unicode版本（Unicode version）

所以在Unicode環境下，它的效果就相當於：

s.Format(L"%d",total);

如果你認為你的程序可能在Unicode的環境下運行，那麼開始在意用 Unicode 編碼。比如說，不要用 sizeof() 操作符來獲得字元串的長度，因為在Unicode環境下就會有2倍的誤差。我們可以用一些方法來隱藏Unicode的一些細節，比如在我需要獲得字元長度的時候，我會用一個叫做DIM的宏，這個宏是在我的dim.h文件中定義的，我會在我寫的所有程序中都包含這個文件：

#define DIM(x) (sizeof((x)) / sizeof((x)[0]))

這個宏不僅可以用來解決Unicode的字元串長度的問題，也可以用在編譯時定義的表格上，它可以獲得表格的項數，如下：

class Whatever { ... };

Whatever data[] = {

{ ... },

...

{ ... },

};

for(int i = 0; i < DIM(data); i++) // 掃描表格尋找匹配項。

這裡要提醒你的就是一定要注意那些在參數中需要真實位元組數的API函數調用，如果你傳遞字元個數給它，它將不能正常工作。如下：TCHAR data[20];

lstrcpyn(data,longstring,sizeof(data) - 1）； // WRONG!

lstrcpyn(data,longstring,DIM(data) - 1）； // RIGHT

WriteFile(f,data,DIM(data),&bytesWritten,NULL); // WRONG!

WriteFile(f,data,sizeof(data),&bytesWritten,NULL); // RIGHT

造成以上原因是因為lstrcpyn需要一個字元個數作為參數，但是WriteFile卻需要位元組數作為參數。

同樣需要注意的是有時候需要寫出數據的所有內容。如果你僅僅只想寫出數據的真實長度，你可能會認為你應該這樣做：

WriteFile(f,data,lstrlen(data),&bytesWritten,NULL); // WRONG

但是在Unicode環境下，它不會正常工作。正確的做法應該是這樣：

WriteFile(f,data,lstrlen(data) * sizeof(TCHAR),&bytesWritten,NULL); // RIGHT

因為WriteFile需要的是一個以位元組為單位的長度。（可能有些人會想"在非Unicode的環境下運行這行代碼，就意味著總是在做一個多餘的乘1操作，這樣不會降低程序的效率嗎？"這種想法是多餘的，你必須要了解編譯器實際上做了什麼，沒有哪一個C或C++編譯器會把這種無聊的乘1操作留在代碼中。在Unicode環境下運行的時候，你也不必擔心那個乘2操作會降低程序的效率，記住，這只是一個左移一位的操作而已。使用_T宏並不是意味著你已經創建了一個Unicode的程序，你只是創建了一個有Unicode意識的程序而已。如果你在默認的8-bit模式下編譯你的程序的話，得到的將是一個普通的8-bit的應用程序（這裡的8-bit指的只是8位的字元編碼，並不是指8位的計算機系統）；當你在Unicode環境下編譯你的程序時，你才會得到一個Unicode的程序。記住，CString 在 Unicode 環境下，裡面包含的可都是16位的字元哦。

成員函數

1） CString類的構造函數

CString類有很多構造函數，這裡只介紹幾個比較常用的：

CString(const CString& stringSrc);

將一個已經存在的CString對象stringSrc的內容拷貝到該CString對象。例如：

CString str1(_T(jizhuomi)); // 將常量字元串拷貝到str1

CString str2(str1）； // 將str1的內容拷貝到str2

CString(LPCTSTR lpch,int nLength);

將字元串lpch中的前nLength個字元拷貝到該CString對象。例如：

CString str(_T("wwwjizhuomi"),3）； // 構造的字元串對象內容為"www"

CString(TCHAR ch,int nLength = 1）；

使用此函數構造的CString對象中將含有nLength個重複的ch字元。例如：

CString str(_T('w'),3）； // str為"www"

2）CString類的大小寫轉換及順序轉換函數

CString& MakeLower(); 將字元串中的所有大寫字元轉換為小寫字元。

CString& MakeUpper(); 將字元串中的所有小寫字元轉換為大寫字元。

CString& MakeReverse(); 將字元串中所有字元的順序顛倒。

例如：

CString str(_T("JiZhuoMi"));

str.MakeLower(); // str為"jizhuomi"

str.MakeUpper(); // str為"JIZHUOMI"

str.MakeReverse(); // str為"IMOUHZIJ"

3）CString對象的連接

多個CString對象的連接可以通過重載運算符+、+=實現。例如：

CString str(_T("jizhuomi")); // str內容為"jizhuomi"

str = _T("www") + str + _T("-"); // str為"wwwjizhuomi-"

str += _T("com"); // str為wwwjizhuomi-com

4）CString對象的比較

CString對象的比較可以通過==、！=、<；、>；、<=、>=等重載運算符實現，也可以使用Compare和CompareNoCase成員函數實現。

int Compare(PCXSTR psz) const;

將該CString對象與psz字元串比較，如果相等則返回0，如果小於psz則返回值小於0，如果大於psz則返回值大於0。

int CompareNoCase(PCXSTR psz) const throw();

此函數與Compare功能類似，只是不區分大小寫。

例如：

5）CString對象字元串的提取操作

CString Left(int nCount) const;

提取該字元串左邊nCount個字元的子字元串，並返回一個包含這個子字元串的拷貝的CString對象。

CString Right(int nCount) const;

提取該字元串右邊nCount個字元的子字元串，並返回一個包含這個子字元串的拷貝的CString對象。

CString Mid(int iFirst,int nCount) const;

提取該字元串中以索引iFirst位置開始的nCount個字元組成的子字元串，並返回一個包含這個子字元串的拷貝的CString對象。

CString Mid(int iFirst) const;

提取該字元串中以索引iFirst位置開始直至字元串結尾的子字元串，並返回一個包含這個子字元串的拷貝的CString對象。

例如：

6）CString對象字元串的查找操作

int Find(PCXSTR pszSub,int iStart=0) const throw();

int Find(XCHAR ch,int iStart=0) const throw();

在CString對象字元串的iStart索引位置開始，查找子字元串pszSub或字元ch第一次出現的位置，如果沒有找到則返回-1。

int FindOneOf(PCXSTR pszCharSet) const throw();

查找pszCharSet字元串中的任意字元，返回第一次出現的位置，找不到則返回-1。

int ReverseFind(XCHAR ch) const throw();

從字元串末尾開始查找指定的字元ch，返回其位置，找不到則返回-1。這裡要注意，儘管是從後向前查找，但是位置的索引還是要從開始算起。

CString str = _T("jizhuomi");

int nIndex1 = str.Find(_T("zh")); // nIndex1的值為2

int nIndex2 = str.FindOneOf(_T("mui")); // nIndex2的值為1

int nIndex3 = str.ReverseFind(_T('i')); // nIndex3的值為7

7）CString類對象字元串的替換與刪除

int Replace(PCXSTR pszOld,PCXSTR pszNew);

用字元串pszNew替換CString對象中的子字元串pszOld，返回替換的字元個數。

int Replace(XCHAR chOld,XCHAR chNew);

用字元chNew替換CString對象中的字元chOld，返回替換的字元個數。

int Delete(int iIndex,int nCount = 1）；

從字元串中刪除iIndex位置開始的nCount個字元，返回刪除操作后的字元串的長度。

int Remove(XCHAR chRemove);

刪除字元串中的所有由chRemove指定的字元，返回刪除的字元個數。

例如：

8）CString類的格式化字元串方法

使用CString類的Format成員函數可以將int、short、long、float、double等數據類型格式化為字元串對象。

void __cdecl Format(PCXSTR pszFormat,[,argument]...);

參數pszFormat為格式控制字元串；參數argument可選，為要格式化的數據，一般每個argument在pszFormat中都有對應的表示其類型的子字元串，int型的argument對應的應該是"%d"，float型的應對應"%f"，等等。

例如：

int型

把 CString 類型的數據轉化成整數類型最簡單的方法就是使用標準的字元串到整數轉換常式。

雖然通常你懷疑使用_atoi()函數是一個好的選擇，它也很少會是一個正確的選擇。如果你準備使用 Unicode 字元，你應該用_ttoi()，它在 ANSI 編碼系統中被編譯成_atoi()，而在 Unicode 編碼系統中編譯成_wtoi()。你也可以考慮使用_tcstoul()或者_tcstol()，它們都能把字元串轉化成任意進位的長整數（如二進位、八進位、十進位或十六進位），不同點在於前者轉化后的數據是無符號的（unsigned），而後者相反。看下面的例子：

CString hex = _T("FAB");

CString decimal = _T("4011");ASSERT(_tcstoul(hex,0,16） == _ttoi(decimal));

Thestrargument to atoiand _wtoihas the following form:

[whitespace] [sign] [digits]]

Awhitespaceconsists of space or tab characters, which are ignored;signis either plus (+) or minus (–); anddigitsare one or more digits.

The versions of these functions with the_lsuffix are identical except that they use the locale parameter passed in instead of the current locale. For more information, seeLocale.

TCHAR.H routine	_UNICODE & _MBCS not defined	_MBCS defined	_UNICODE defined
_tstoi	atoi	atoi	_wtoi
_ttoi	atoi	atoi	_wtoi

類型轉換

char*轉換

這是初學者使用 CString 時最常見的問題。有了 C++ 的幫助，很多問題你不需要深入的去考慮它，直接拿來用就行了，但是如果你不能深入了解它的運行機制，又會有很多問題讓你迷惑，特別是有些看起來沒有問題的代碼，卻偏偏不能正常工作。

比如，你會奇怪為什麼不能寫像下面這樣的代碼呢：

CString graycat = "Gray" + "Cat";

或者這樣：

CString graycat("Gray" + "Cat");

事實上，編譯器將抱怨上面的這些嘗試。為什麼呢？因為針對CString 和 LPCTSTR數據類型的各種各樣的組合，" +" 運算符被定義成一個重載操作符。而不是兩個 LPCTSTR數據類型，它是底層數據類型。你不能對基本數據（如 int、char 或者 char*）類型重載C++ 的運算符。你可以像下面這樣做：

CString graycat = CString("Gray") + CString("Cat");

或者這樣：

CString graycat = CString("Gray") + "Cat";

研究一番就會發現：" +"總是使用在至少有一個 CString 對象和一個 LPCSTR 的場合。

注意，編寫有 Unicode 意識的代碼總是一件好事，比如：

CString graycat = CString(_T("Gray")) + _T("Cat");

這將使得你的代碼可以直接移植。

char* 轉化為 CString

你有一個 char* 類型的數據，或者說一個字元串。怎麼樣創建 CString 對象呢？這裡有一些例子：

char * p = "This is a test";

或者像下面這樣更具有 Unicode 意識：

TCHAR * p = _T("This is a test")

或

LPTSTR p = _T("This is a test");

你可以使用下面任意一種寫法：

用這些方法可以輕鬆將常量字元串或指針轉換成 CString。需要注意的是，字元的賦值總是被拷貝到 CString 對象中去的，所以你可以像下面這樣操作：

結果字元串肯定是"GrayCat"。

CString 類還有幾個其它的構造函數，但是這裡我們不考慮它，如果你有興趣可以自己查看相關文檔。

事實上，CString 類的構造函數比我展示的要複雜，比如：

CString s = "This is a test";

這是很草率的編碼，但是實際上它在 Unicode 環境下能編譯通過。它在運行時調用構造函數的MultiByteToWideChar操作將 8 位字元串轉換成 16 位字元串。不管怎樣，如果 char *指針是網路上傳輸的 8 位數據，這種轉換是很有用的。

CString 轉化成 char* 之一：強制類型轉換為 LPCTSTR；

這是一種略微硬性的轉換，有關"正確"的做法，人們在認識上還存在許多混亂，正確的使用方法有很多，但錯誤的使用方法可能與正確的使用方法一樣多。

我們首先要了解 CString 是一種很特殊的 C++ 對象，它裡面包含了三個值：一個指向某個數據緩衝區的指針、一個是該緩衝中有效的字元記數以及一個緩衝區長度。有效字元數的大小可以是從0到該緩衝最大長度值減1之間的任何數（因為字元串結尾有一個NULL字元）。字元記數和緩衝區長度被巧妙隱藏。

除非你做一些特殊的操作，否則你不可能知道給CString對象分配的緩衝區的長度。這樣，即使你獲得了該0緩衝的地址，你也無法更改其中的內容，不能截短字元串，也絕對沒有辦法加長它的內容，否則第一時間就會看到溢出。

LPCTSTR 操作符（或者更明確地說就是 TCHAR * 操作符）在 CString 類中被重載了，該操作符的定義是返回緩衝區的地址，因此，如果你需要一個指向 CString 的字元串指針的話，可以這樣做：

CString s("GrayCat");

LPCTSTR p = s;

它可以正確地運行。這是由C語言的強制類型轉化規則實現的。當需要強制類型轉化時，C++規則容許這種選擇。比如，你可以將（浮點數）定義為將某個複數（有一對浮點數）進行強制類型轉換后只返回該複數的第一個浮點數（也就是其實部）。可以像下面這樣：

Complex c（1.2f,4.8f);

float realpart = c;

如果（float）操作符定義正確的話，那麼實部的的值應該是1.2。

這種強制轉化適合所有這種情況，例如，任何帶有 LPCTSTR 類型參數的函數都會強制執行這種轉換。於是，你可能有這樣一個函數（也許在某個你買來的DLL中）：

BOOL DoSomethingCool(LPCTSTR s);

你像下面這樣調用它：

CString file("c:\\myfiles\\coolstuff")

BOOL result = DoSomethingCool(file);

它能正確運行。因為 DoSomethingCool 函數已經說明了需要一個 LPCTSTR 類型的參數，因此 LPCTSTR 被應用於該參數，在 MFC 中就是返回的串地址。

如果你要格式化字元串怎麼辦呢？

注意由於在可變參數列表中的值（在函數說明中是以"..."表示的）並沒有隱含一個強制類型轉換操作符。你會得到什麼結果呢？

一個令人驚訝的結果，我們得到的實際結果串是：

"Mew! I love GrayCat"。

因為 MFC 的設計者們在設計 CString數據類型時非常小心， CString 類型表達式求值后指向了字元串，所以這裡看不到任何象 Format 或 sprintf 中的強制類型轉換，你仍然可以得到正確的行為。描述 CString 的附加數據實際上在 CString 名義地址之後。

有一件事情你是不能做的，那就是修改字元串。比如，你可能會嘗試用","代替"."（不要做這樣的，如果你在乎國際化問題，你應該使用十進位轉換的 National Language Support 特性，），下面是個簡單的例子：

CString v("1.00"); // 貨幣金額，兩位小數

LPCTSTR p = v;

p[lstrlen(p) - 3] =,;

這時編譯器會報錯，因為你賦值了一個常量串。如果你做如下嘗試，編譯器也會錯：

strcat(p,"each");

因為 strcat 的第一個參數應該是 LPTSTR 類型的數據，而你卻給了一個 LPCTSTR。

不要試圖鑽這個錯誤消息的牛角尖，這隻會使你自己陷入麻煩！

原因是緩衝有一個計數，它是不可存取的（它位於 CString 地址之下的一個隱藏區域），如果你改變這個串，緩衝中的字元計數不會反映所做的修改。此外，如果字元串長度恰好是該字元串物理限制的長度（梢后還會講到這個問題），那麼擴展該字元串將改寫緩衝以外的任何數據，那是你無權進行寫操作的內存（不對嗎？），你會毀換壞不屬於你的內存。這是應用程序真正的死亡處方。

CString轉化成char* 之二：使用 CString 對象的 GetBuffer 方法；

如果你需要修改 CString 中的內容，它有一個特殊的方法可以使用，那就是 GetBuffer，它的作用是返回一個可寫的緩衝指針。如果你只是打算修改字元或者截短字元串，你完全可以這樣做：

這是 GetBuffer 的第一種用法，也是最簡單的一種，不用給它傳遞參數，它使用默認值 0，意思是："給我這個字元串的指針，我保證不加長它"。當你調用 ReleaseBuffer 時，字元串的實際長度會被重新計算，然後存入 CString 對象中。

必須強調一點，在 GetBuffer 和 ReleaseBuffer 之間這個範圍，一定不能使用你要操作的這個緩衝的 CString 對象的任何方法。因為 ReleaseBuffer 被調用之前，該 CString 對象的完整性得不到保障。研究以下代碼：

假設你想增加字元串的長度，你首先要知道這個字元串可能會有多長，好比是聲明字元串數組的時候用：

char buffer[1024];

表示 1024 個字元空間足以讓你做任何想做得事情。在 CString 中與之意義相等的表示法：

LPTSTR p = s.GetBuffer（1024）；

調用這個函數后，你不僅獲得了字元串緩衝區的指針，而且同時還獲得了長度至少為 1024 個字元的空間（注意，我說的是"字元"，而不是"位元組"，因為 CString 是以隱含方式感知 Unicode 的）。

同時，還應該注意的是，如果你有一個常量串指針，這個串本身的值被存儲在只讀內存中，如果試圖存儲它，即使你已經調用了 GetBuffer ，並獲得一個只讀內存的指針，存入操作會失敗，並報告存取錯誤。我沒有在 CString 上證明這一點，但我看到過大把的 C 程序員經常犯這個錯誤。

C 程序員有一個通病是分配一個固定長度的緩衝，對它進行 sprintf 操作，然後將它賦值給一個 CString：

雖然更好的形式可以這麼做：

如果你的字元串長度萬一超過 256 個字元的時候，不會破壞堆棧。

另外一個常見的錯誤是：既然固定大小的內存不工作，那麼就採用動態分配位元組，這種做法弊端更大：

它可以能被簡單地寫成：

需要注意 sprintf 例子都不是 Unicode 就緒的，儘管你可以使用 tsprintf 以及用 _T() 來包圍格式化字元串，但是基本思路仍然是在走彎路，這這樣很容易出錯。

CString to char * 之三：和控制項的介面；

我們經常需要把一個 CString 的值傳遞給一個控制項，比如，CTreeCtrl。MFC為我們提供了很多便利來重載這個操作，但是在大多數情況下，你使用"原始"形式的更新，因此需要將墨某個串指針存儲到 TⅥNSERTITEMSTRUCT 結構的TⅥTEM成員中。如下：

為什麼編譯器會報錯呢？明明看起來很完美的用法啊！但是事實上如果你看看TⅥTEM結構的定義你就會明白，在TⅥTEM結構中 pszText 成員的聲明如下：

因此，賦值不是賦給一個 LPCTSTR 類型的變數，而且編譯器無法知道如何將賦值語句右邊強制轉換成 LPCTSTR。好吧，你說，那我就改成這樣：

tvi.item.pszText = (LPCTSTR)s; //編譯器依然會報錯。

編譯器之所以依然報錯是因為你試圖把一個 LPCTSTR 類型的變數賦值給一個 LPTSTR 類型的變數，這種操作在C或C++中是被禁止的。你不能用這種方法來濫用常量指針與非常量指針概念，否則，會擾亂編譯器的優化機制，使之不知如何優化你的程序。比如，如果你這麼做：

那麼，編譯器會以為既然 i 是 const ，所以 usage1和usage2的值是相同的，並且它甚至能事先計算好 usage1 處的 a 的地址，然後保留著在後面的 usage2 處使用，而不是重新計算。如果你按如下方式寫的話：

編譯器將認為 i 是常量，從而 a 的位置也是常量，這樣間接地破壞了先前的假設。因此，你的程序將會在 debug 編譯模式（沒有優化）和 release 編譯模式（完全優化）中反映出不同的行為，這種情況可不好，所以當你試圖把指向 i 的指針賦值給一個可修改的引用時，會被編譯器診斷為這是一種偽造。這就是為什麼（LPCTSTR）強制類型轉化不起作用的原因。

為什麼不把該成員聲明成 LPCTSTR 類型呢？因為這個結構被用於讀寫控制項。當你向控制項寫數據時，文本指針實際上被當成 LPCTSTR，而當你從控制項讀數據時，你必須有一個可寫的字元串。這個結構無法區分它是用來讀還是用來寫。

因此，你會常常在我的代碼中看到如下的用法：

tvi.item.pszText = (LPTSTR)(LPCTSTR)s;

它把 CString 強制類型轉化成 LPCTSTR，也就是說先獲得改字元串的地址，然後再強制類型轉化成 LPTSTR，以便可以對之進行賦值操作。注意這隻有在使用 Set 或 Insert 之類的方法才有效！如果你試圖獲取數據，則不能這麼做。

如果你打算獲取存儲在控制項中的數據，則方法稍有不同，例如，對某個 CTreeCtrl 使用 GetItem 方法，我想獲取項目的文本。我知道這些文本的長度不會超過 MY_LIMIT，因此我可以這樣寫：

可以看出來，其實上面的代碼對所有類型的 Set 方法都適用，但是並不需要這麼做，因為所有的類 Set 方法（包括 Insert方法）不會改變字元串的內容。但是當你需要寫 CString 對象時，必須保證緩衝是可寫的，這正是 GetBuffer 所做的事情。再次強調：一旦做了一次 GetBuffer 調用，那麼在調用 ReleaseBuffer 之前不要對這個 CString 對象做任何操作。

BSTR 型轉換

CString型轉為BSTR

當我們使用 ActiveX 控制項編程時，經常需要用到將某個值表示成 BSTR 類型。BSTR 是一種記數字元串，Intel平台上的寬字元串（Unicode），並且可以包含嵌入的 NULL 字元。

你可以調用 CString 對象的 AllocSysString 方法將 CString 轉化成 BSTR：

現指針b 指向的就是一個新分配的 BSTR 對象，該對象是 CString 的一個拷貝，包含終結 NULL字元。你可以將它傳遞給任何需要 BSTR 的介面。通常，BSTR 由接收它的組件來釋放，如果你需要自己釋放 BSTR 的話，可以這麼做：

：：SysFreeString(b);

對於如何表示傳遞給 ActiveX 控制項的字元串，在微軟內部曾一度爭論不休，最後 Visual Basic 的人佔了上風，BSTR（"Basic String"的首字母縮寫）就是這場爭論的結果。

BSTR 型轉為CString

由於 BSTR 是記數 Unicode 字元串，你可以用標準轉換方法來創建 8 位的 CString。實際上，這是 CString 內建的功能。在 CString 中有特殊的構造函數可以把 ANSI 轉化成 Unicode，也可以把Unicode 轉化成 ANSI。你同樣可以從 VARIANT 類型的變數中獲得 BSTR 類型的字元串，VARIANT 類型是由各種 COM 和 Automation （自動化）調用返回的類型。

例如，在一個ANSI程序中：

對於單個的 BSTR 串來說，這種用法可以工作得很好，這是因為 CString 有一個特殊的構造函數以LPCWSTR（BSTR正是這種類型）為參數，並將它轉化成 ANSI 類型。專門檢查是必須的，因為 BSTR 可能為空值，而 CString 的構造函數對於 NULL 值情況考慮的不是很周到，（感謝 Brian Ross 指出這一點！）。這種用法也只能處理包含 NUL 終結字元的單字元串；如果要轉化含有多個 NULL 字元串，你得額外做一些工作才行。在 CString 中內嵌的 NULL 字元通常表現不盡如人意，應該盡量避免。

根據 C/C++ 規則，如果你有一個 LPWSTR，那麼它別無選擇，只能和 LPCWSTR 參數匹配。

在 Unicode 模式下，它的構造函數是：

CString::CString(LPCTSTR);

正如上面所表示的，在 ANSI 模式下，它有一個特殊的構造函數：

CString::CString(LPCWSTR);

它會調用一個內部的函數將 Unicode 字元串轉換成 ANSI 字元串。（在Unicode模式下，有一個專門的構造函數，該函數有一個參數是LPCSTR類型——一個8位 ANSI 字元串指針，該函數將它加寬為 Unicode 的字元串！）再次強調：一定要檢查 BSTR 的值是否為 NULL。

另外還有一個問題，正如上文提到的：BSTRs可以含有多個內嵌的NULL字元，但是 CString 的構造函數只能處理某個串中單個 NULL 字元。也就是說，如果串中含有嵌入的 NUL位元組，CString 將會計算出錯誤的串長度。你必須自己處理它。如果你看看 strcore.cpp 中的構造函數，你會發現它們都調用了lstrlen，也就是計算字元串的長度。

注意從 Unicode 到 ANSI 的轉換使用帶專門參數的 ::WideCharToMultiByte，如果你不想使用這種默認的轉換方式，則必須編寫自己的轉化代碼。

如果你在 UNICODE 模式下編譯代碼，你可以簡單地寫成：

如果是 ANSI 模式，則需要更複雜的過程來轉換。注意這個代碼使用與 ::WideCharToMultiByte相同的參數值。所以你只能在想要改變這些參數進行轉換時使用該技術。例如，指定不同的默認字元，不同的標誌集等。

我並不擔心如果 BSTR 包含沒有映射到 8 位字符集的 Unicode 字元時會發生什麼，因為我指定了：：WideCharToMultiByte的最後兩個參數為 NULL。這就是你可能需要改變的地方。

VARIANT 轉換

事實上，我從來沒有這麼做過，因為我沒有用 COM/OLE/ActiveX 編寫過程序。但是我在microsoft.public.vc.mfc 新聞組上看到了 Robert Quirk 的一篇帖子談到了這種轉化，我覺得把他的文章包含在我的文章里是不太好的做法，所以在這裡多做一些解釋和演示。如果和他的文章有相孛的地方可能是我的疏忽。

VARIANT 類型經常用來給 COM 對象傳遞參數，或者接收從 COM 對象返回的值。你也能自己編寫返回 VARIANT 類型的方法，函數返回什麼類型依賴可能（並且常常）方法的輸入參數（比如，在自動化操作中，依賴與你調用哪個方法。IDispatch::Invoke 可能返回（通過其一個參數）一個包含有BYTE、WORD、float、double、date、BSTR 鵲?VARIANT 類型的結果，（詳見 MSDN 上的 VARIANT 結構的定義）。在下面的例子中，假設類型是一個BSTR的變體，也就是說在串中的值是通過 bsrtVal 來引用，其優點是在 ANSI 應用中，有一個構造函數會把 LPCWCHAR 引用的值轉換為一個 CString（見 BSTR-to-CString 部分）。在 Unicode 模式中，將成為標準的 CString構造函數，參見對預設：：WideCharToMultiByte轉換的告誡，以及你覺得是否可以接受（大多數情況下，你會滿意的）。

你還可以根據 vt 域的不同來建立更通用的轉換常式。為此你可能會考慮：

... 剩下的類型轉換由讀者自己完成

字元資源

如果你想創建一個容易進行語言版本移植的應用程序，你就不能在你的源代碼中直接包含本土語言字元串（下面這些例子我用的語言都是英語，因為我的本土語是英語），比如下面這種寫法就很糟：CString s = "There is an error";

你應該把你所有特定語言的字元串單獨擺放（調試信息、在發布版本中不出現的信息除外）。這意味著向下面這樣寫比較好：

在你的程序中，文字字元串不是語言敏感的。不管怎樣，你必須很小心，不要使用下面這樣的串：

這是我的切身體會。在我的第一個國際化的應用程序中我犯了這個錯誤，儘管我懂德語，知道在德語的語法中動詞放在句子的最後面，我們的德國方面的發行人還是苦苦的抱怨他們不得不提取那些不可思議的德語錯誤提示信息然後重新格式化以讓它們能正常工作。比較好的辦法是使用兩個字元串，一個用於讀，一個用於寫，在使用時載入合適的版本，使得它們對字元串參數是非敏感的。也就是說載入整個格式，而不是載入串"reading"，"writing"：

一定要注意，如果你有好幾個地方需要替換，你一定要保證替換后句子的結構不會出現問題，比如在英語中，可以是主語-賓語，主語-謂語，動詞-賓語的結構等等。

在這裡，我們並不討論 FormatMessage，其實它比 sprintf/Format 還要有優勢，但是不太容易和CString 結合使用。解決這種問題的辦法就是我們按照參數出現在參數表中的位置給參數取名字，這樣在你輸出的時候就不會把他們的位置排錯了。

接下來我們討論我們這些獨立的字元串放在什麼地方。我們可以把字元串的值放入資源文件中的一個稱為 STRINGTABLE 的段中。過程如下：首先使用 Visual Studio 的資源編輯器創建一個字元串，然後給每一個字元串取一個ID，一般我們給它取名字都以 IDS_開頭。所以如果你有一個信息，你可以創建一個字元串資源然後取名為 IDS_READING_FILE，另外一個就取名為 IDS_WRITING_FILE。它們以下面的形式出現在你的 .rc 文件中：

注意：這些資源都以 Unicode 的格式保存，不管你是在什麼環境下編譯。他們在Win9x系統上也是以Unicode 的形式存在，雖然 Win9x 不能真正處理 Unicode。

然後你可以這樣使用這些資源：

你的代碼可以移植到任何語言中去了。LoadString 方法需要一個字元串資源的 ID 作為參數，然後它從 STRINGTABLE 中取出它對應的字元串，賦值給 CString 對象。CString 對象的構造函數還有一個更加聰明的特徵可以簡化 STRINGTABLE 的使用。這個用法在 CString::CString 的文檔中沒有指出，但是在構造函數的示常式序中使用了。（為什麼這個特性沒有成為正式文檔的一部分，而是放在了一個例子中，我記不得了！）——【譯者註：從這句話看，作者可能是CString的設計者。其實前面還有一句類似的話。說他沒有對使用GetBuffer(0）獲得的指針指向的地址是否可讀做有效性檢查】。這個特徵就是：如果你將一個字元串資源的ID強制類型轉換為 LPCTSTR，將會隱含調用 LoadString。因此，下面兩個構造字元串的例子具有相同的效果，而且其 ASSERT 在debug模式下不會被觸發：

你可能會想：這怎麼可能工作呢？我們怎麼能把 STRINGTABLE ID 轉化成一個指針呢？很簡單：所有的字元串 ID 都在1~65535這個範圍內，也就是說，它所有的高位都是0，而我們在程序中所使用的指針是不可能小於65535的，因為程序的低 64K 內存永遠也不可能存在的，如果你試圖訪問0x00000000到0x0000FFFF之間的內存，將會引發一個內存越界錯誤。所以說1~65535的值不可能是一個內存地址，所以我們可以用這些值來作為字元串資源的ID。

我傾向於使用 MAKEINTRESOURCE 宏顯式地做這種轉換。我認為這樣可以讓代碼更加易於閱讀。這是個只適合在 MFC 中使用的標準宏。你要記住，大多數的方法即可以接受一個 UINT 型的參數，也可以接受一個 LPCTSTR 型的參數，這是依賴 C++ 的重載功能做到的。C++重載函數帶來的弊端就是造成所有的強制類型轉化都需要顯示聲明。同樣，你也可以給很多種結構只傳遞一個資源名。

告訴你吧：我不僅只是在這裡鼓吹，事實上我也是這麼做的。在我的代碼中，你幾乎不可能找到一個字元串，當然，那些只是偶然在調試中出現的或者和語言無關的字元串除外。

臨時對象

這是出現在 microsoft.public.vc.mfc 新聞組中的一個小問題，我簡單的提一下，這個問題是有個程序員需要往註冊表中寫入一個字元串，他寫道：

我試著用 RegSetValueEx() 設置一個註冊表鍵的值，但是它的結果總是令我困惑。當我用char[]聲明一個變數時它能正常工作，但是當我用 CString 的時候，總是得到一些垃圾："YYYY...YYYYYY"為了確認是不是我的 CString 數據出了問題，我試著用 GetBuffer，然後強制轉化成 char*，LPCSTR。GetBuffer 返回的值是正確的，但是當我把它賦值給 char* 時，它就變成垃圾了。以下是我的程序段：

這個 Name 字元串的長度小於 20，所以我不認為是 GetBuffer 的參數的問題。

真讓人困惑，請幫幫我。

親愛的 Frustrated，

你犯了一個相當微妙的錯誤，聰明反被聰明誤，正確的代碼應該象下面這樣：

為什麼我寫的代碼能行而你寫的就有問題呢？主要是因為當你調用 GetName 時返回的 CString 對象是一個臨時對象。參見：《C++ Reference manual》§12.2

在一些環境中，編譯器有必要創建一個臨時對象，這樣引入臨時對象是依賴於實現的。如果編譯器引入的這個臨時對象所屬的類有構造函數的話，編譯器要確保這個類的構造函數被調用。同樣的，如果這個類聲明有析構函數的話，也要保證這個臨時對象的析構函數被調用。

編譯器必須保證這個臨時對象被銷毀了。被銷毀的確切地點依賴於實現.....這個析構函數必須在退出創建該臨時對象的範圍之前被調用。

大部分的編譯器是這樣設計的：在臨時對象被創建的代碼的下一個執行步驟處隱含調用這個臨時對象的析構函數，實現起來，一般都是在下一個分號處。因此，這個 CString 對象在 GetBuffer 調用之後就被析構了（順便提一句，你沒有理由給 GetBuffer 函數傳遞一個參數，而且沒有使用ReleaseBuffer 也是不對的）。所以 GetBuffer 本來返回的是指向這個臨時對象中字元串的地址的指針，但是當這個臨時對象被析構后，這塊內存就被釋放了。然後 MFC 的調試內存分配器會重新為這塊內存全部填上 0xDD，顯示出來剛好就是"Y"符號。在這個時候你向註冊表中寫數據，字元串的內容當然全被破壞了。

我們不應該立即把這個臨時對象轉化成 char* 類型，應該先把它保存到一個 CString 對象中，這意味著把臨時對象複製了一份，所以當臨時的 CString 對象被析構了之後，這個 CString 對象中的值依然保存著。這個時候再向註冊表中寫數據就沒有問題了。

此外，我的代碼是具有 Unicode 意識的。那個操作註冊表的函數需要一個位元組大小，使用lstrlen(Name+1）得到的實際結果對於 Unicode字元來說比 ANSI 字元要小一半，而且它也不能從這個字元串的第二個字元起開始計算，也許你的本意是 lstrlen(Name) + 1（OK，我承認，我也犯了同樣的錯誤！）。不論如何，在 Unicode 模式下，所有的字元都是2個位元組大小，我們需要處理這個問題。微軟的文檔令人驚訝地對此保持緘默：REG_SZ 的值究竟是以位元組計算還是以字元計算呢？我們假設它指的是以位元組為單位計算，你需要對你的代碼做一些修改來計算這個字元串所含有的位元組大小。

效率

CString 的一個問題是它確實掩藏了一些低效率的東西。從另外一個方面講，它也確實可以被實現得更加高效，你可能會說下面的代碼：

比起下面的代碼來，效率要低多了：

總之，你可能會想，首先，它為 SomeCString1 分配一塊內存，然後把 SomeCString1 複製到裡面，然後發現它要做一個連接，則重新分配一塊新的足夠大的內存，大到能夠放下當前的字元串加上SomeCString2，把內容複製到這塊內存，然後把 SomeCString2 連接到後面，然後釋放第一塊內存，並把指針重新指向新內存。然後為每個字元串重複這個過程。把這 4 個字元串連接起來效率多低啊。事實上，在很多情況下根本就不需要複製源字元串（在 += 操作符左邊的字元串）。

在 VC++6.0 中，Release 模式下，所有的 CString 中的緩存都是按預定義量子分配的。所謂量子，即確定為 64、128、256 或者 512 位元組。這意味著除非字元串非常長，連接字元串的操作實際上就是 strcat 經過優化后的版本（因為它知道本地的字元串應該在什麼地方結束，所以不需要尋找字元串的結尾；只需要把內存中的數據拷貝到指定的地方即可）加上重新計算字元串的長度。所以它的執行效率和純 C 的代碼是一樣的，但是它更容易寫、更容易維護和更容易理解。

如果你還是不能確定究竟發生了怎樣的過程，請看看 CString 的源代碼，strcore.cpp，在你 vc98的安裝目錄的 mfc\src 子目錄中。看看 ConcatInPlace 方法，它被在所有的 += 操作符中調用。

啊哈！難道 CString 真的這麼"高效"嗎？比如，如果我創建

CString cat("Mew!");

然後我並不是得到了一個高效的、精簡的5個位元組大小的緩衝區（4個字元加一個結束字元），系統將給我分配64個位元組，而其中59個位元組都被浪費了。

如果你也是這麼想的話，那麼就請準備好接受再教育吧。可能在某個地方某個人給你講過盡量使用少的空間是件好事情。不錯，這種說法的確正確，但是他忽略了事實中一個很重要的方面。

如果你編寫的是運行在16K EPROMs下的嵌入式程序的話，你有理由盡量少使用空間，在這種環境下，它能使你的程序更健壯。但是在 500MHz,256MB的機器上寫 Windows 程序，如果你還是這麼做，它只會比你認為的"低效"的代碼運行得更糟。

舉例來說。字元串的大小被認為是影響效率的首要因素，使字元串儘可能小可以提高效率，反之則降低效率，這是大家一貫的想法。但是這種想法是不對的，精確的內存分配的後果要在程序運行了好幾個小時后才能體現得出來，那時，程序的堆中將充滿小片的內存，它們太小以至於不能用來做任何事，但是他們增加了你程序的內存用量，增加了內存頁面交換的次數，當頁面交換的次數增加到系統能夠忍受的上限，系統則會為你的程序分配更多的頁面，直到你的程序佔用了所有的可用內存。由此可見，雖然內存碎片是決定效率的次要因素，但正是這些因素實際控制了系統的行為，最終，它損害了系統的可靠性，這是令人無法接受的。

記住，在 debug 模式下，內存往往是精確分配的，這是為了更好的排錯。

假設你的應用程序通常需要連續工作好幾個月。比如，我常打開 VC++，Word，PowerPoint，Frontpage，Outlook Express，Forté Agent，Internet Explorer和其它的一些程序，而且通常不關閉它們。我曾經夜以繼日地連續用 PowerPoint 工作了好幾天（反之，如果你不幸不得不使用像 Adobe FrameMaker 這樣的程序的話，你將會體會到可靠性的重要；這個程序機會每天都要崩潰4~6次，每次都是因為用完了所有的空間並填滿我所有的交換頁面）。所以精確內存分配是不可取的，它會危及到系統的可靠性，並引起應用程序崩潰。

按量子的倍數為字元串分配內存，內存分配器就可以回收用過的內存塊，通常這些回收的內存塊馬上就可以被其它的 CString 對象重新用到，這樣就可以保證碎片最少。分配器的功能加強了，應用程序用到的內存就能儘可能保持最小，這樣的程序就可以運行幾個星期或幾個月而不出現問題。

題外話：很多年以前，我們在 CMU 寫一個互動式系統的時候，一些對內存分配器的研究顯示出它往往產生很多內存碎片。Jim Mitchell，他在 Sun Microsystems 工作，那時候他創造了一種內存分配器，它保留了一個內存分配狀況的運行時統計表，這種技術和當時的主流分配器所用的技術都不同，且較為領先。當一個內存塊需要被分割得比某一個值小的話，他並不分割它，因此可以避免產生太多小到什麼事都幹不了的內存碎片。事實上他在內存分配器中使用了一個浮動指針，他認為：與其讓指令做長時間的存取內存操作，還不如簡單的忽略那些太小的內存塊而只做一些浮動指針的操作。（His observation was that the long-term saving in instructions by not having to ignore unusable small storage chunks far and away exceeded the additional cost of doing a few floating point operations on an allocation operation.）他是對的。

永遠不要認為所謂的"最優化"是建立在每一行代碼都高速且節省內存的基礎上的，事實上，高速且節省內存應該是在一個應用程序的整體水平上考慮的。在軟體的整體水平上，只使用最小內存的字元串分配策略可能是最糟糕的一種方法。

如果你認為優化是你在每一行代碼上做的那些努力的話，你應該想一想：在每一行代碼中做的優化很少能真正起作用。

記住，+= 運算符只是一種特例，如果你寫成下面這樣：

CString s = SomeCString1 + SomeCString2 + SomeCString3 + "," + SomeCString4;

則每一個 + 的應用會造成一個新的字元串被創建和一次複製操作。

總結

以上是使用 CString 的一些技巧。我每天寫程序的時候都會用到這些。CString 並不是一種很難使用的類，但是 MFC 沒有很明顯的指出這些特徵，需要你自己去探索、去發現。

CString

CString

介紹

前言

對象連接

字元串

成員函數

int型

類型轉換

字元資源

臨時對象

效率

總結

基本信息