CString

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

基本介紹

• 中文名：字元數組
• 外文名：CString
• 套用學科：計算機軟體
• 軟體語言：Visual C++
• 適用系統：MFC ATL
• 屬性：數據類型定義

前言

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 類型，你能很方便地連線兩個字元串，正如下面的例子：

CString gray("Gray");CString cat("Cat");CString graycat = gray + cat;//then graycat="GrayCat"

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

char gray[] = "Gray";char cat[] = "Cat";char * graycat =(char*)malloc(strlen(gray) + strlen(cat) + 1);strcpy(graycat,gray);strcat(graycat,cat);

字元串

與其用 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功能類似，只是不區分大小寫。

例如：

CString str1 = _T("JiZhuoMi");CString str2 = _T("jizhuomi");if (str1 == str2）{// 因為str1、str2不相等，所以不執行下面的代碼...}if (0 == str1.CompareNoCase(str2））{// 因為不區分大小寫比較時，CompareNoCase函式返回0，所以執行下面的代碼...}

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對象。

例如：

CString str1 = _T("jizhuomi");CString str2 = str1.Left⑶； // str2為"jiz"str2 = str1.Right⑵； // str2為"mi"str2 = str1.Mid（1,3）； // str2為"izh"str2 = str1.Mid⑸； // str2為"omi"

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指定的字元，返回刪除的字元個數。

例如：

CString str = _T("jizhuomi");int n1 = str.Replace(_T('i'),_T('j')); // str為"jjzhuomj"，n1為2int n2 = str.Delete（1,2）； // str為"jhuomj"，n2為6int n3 = str.Remove(_T('j')); // str為"ihuom"，n3為1

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

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

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

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

例如：

CString str;int a = 1;float b = 2.3f;str.Format(_T("a=%d,b=%f"),a,b); // str為"a=1,b=2.300000"

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 toatoiand_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 s = "This is a test"; // 8-bit onlyCString s = _T("This is a test"); // Unicode-awareCString s("This is a test"); // 8-bit onlyCString s(_T("This is a test")); // Unicode-awareCString s = p;CString s(p);

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

TCHAR * p = _T("Gray");CString s(p);p = _T("Cat");s += p;

結果字元串肯定是"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 中就是返回的串地址。

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

CString graycat("GrayCat");CString s;s.Format("Mew! I love %s",graycat);

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

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

"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，它的作用是返回一個可寫的緩衝指針。如果你只是打算修改字元或者截短字元串，你完全可以這樣做：

CString s(_T("File.ext"));LPTSTR p = s.GetBuffer();LPTSTR dot = strchr(p,.); // OK,should have used s.Find...if(p != NULL)*p = _T(\0);s.ReleaseBuffer();

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

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

CString s(...);LPTSTR p = s.GetBuffer();//... 這個指針p 發生了很多事情int n = s.GetLength(); // 很糟D!!!!! 有可能給出錯誤的答案！！！s.TrimRight(); // 很糟！！！!! 不能保證能正常工作！！!!s.ReleaseBuffer(); // 應該 OKint m = s.GetLength(); // 這個結果可以保證是正確的。s.TrimRight(); // 將正常工作。

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

char buffer[1024];

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

LPTSTR p = s.GetBuffer（1024）；

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

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

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

char buffer[256];sprintf(buffer,"%......",args,...); // ... 部分省略許多細節CString s = buffer;

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

CString s;s.Format(_T("%...."),args,...);

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

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

int len = lstrlen(parm1） + 13 lstrlen(parm2） + 10 + 100;char * buffer = new char[len];sprintf(buffer,"%s is equal to %s,valid data",parm1,parm2）；CString s = buffer;......delete [] buffer;

它可以能被簡單地寫成：

CString s;s.Format(_T("%s is equal to %s,valid data"),parm1,parm2）；

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

CString to char * 之三：和控制項的接口；

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

TⅥNSERTITEMSTRUCT tvi;CString s;// ... 為s賦一些值。tvi.item.pszText = s; // Compiler yells at you here// ... 填寫tvi的其他域HTREEITEM ti = c_MyTree.InsertItem(&tvi);

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

LPTSTR pszText;int cchTextMax;

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

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

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

const int i = ...;//... do lots of stuff... = a; // usage 1// ... lots more stuff... = a; // usage 2

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

const int i = ...;int * p = &i;//... do lots of stuff... = a; // usage 1// ... lots more stuff（*p)++; // mess over compilers assumption// ... and other stuff... = a; // usage 2

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

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

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

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

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

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

TⅥTEM tvi;// ... assorted initialization of other fields of tvitvi.pszText = s.GetBuffer(MY_LIMIT);tvi.cchTextMax = MY_LIMIT;c_MyTree.GetItem(&tvi);s.ReleaseBuffer();

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

BSTR 型轉換

CString型轉為BSTR

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

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

CString s;s = ... ; // whateverBSTR b = s.AllocSysString();

現指針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 b;b = ...; // whateverCString s(b == NULL L"" : b)

對於單個的 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 模式下編譯代碼，你可以簡單地寫成：

CString convert(BSTR b){if(b == NULL)return CString(_T(""));CString s(b); // in UNICODE modereturn s;}

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

CString convert(BSTR b){CString s;if(b == NULL)return s; // empty for NULL BSTR#ifdef UNICODEs = b;#elseLPSTR p = s.GetBuffer(SysStringLen(b) + 1）；：：WideCharToMultiByte(CP_ACP,// ANSI Code Page0,// no flagsb,// source widechar string-1,// assume NUL-terminatedp,// target bufferSysStringLen(b)+1,// target buffer lengthNULL,// use system default charNULL); // dont care if default useds.ReleaseBuffer();#endifreturn s;}

我並不擔心如果 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轉換的告誡，以及你覺得是否可以接受（大多數情況下，你會滿意的）。

VARIANT vaData;vaData = m_com.YourMethodHere();ASSERT(vaData.vt == VT_BSTR);CString strData(vaData.bstrVal);

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

CString VariantToString(VARIANT * va){CString s;switch(va->vt){ /* vt */case VT_BSTR:return CString(vaData->bstrVal);case VT_BSTR | VT_BYREF:return CString(*vaData->pbstrVal);case VT_I4:s.Format(_T("%d"),va->lVal);return s;case VT_I4 | VT_BYREF:s.Format(_T("%d"),*va->plVal);case VT_R8:s.Format(_T("%f"),va->dblVal);return s;

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

default:ASSERT(FALSE); // unknown VARIANT type (this ASSERT is optional)return CString("");} /* vt */}

字元資源

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

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

s.Format(_T("%d - %s"),code,text);

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

// fmt is "Error in %s file %s"// readorwrite is "reading" or "writing"s.Format(fmt,readorwrite,filename);

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

// fmt is "Error in reading file %s"// "Error in writing file %s"s.Format(fmt,filename);

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

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

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

STRINGTABLEIDS_READING_FILE "Reading file %s"IDS_WRITING_FILE "Writing file %s"END

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

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

// 在使用資源串表之前，程式是這樣寫的：CString fmt;if(...)fmt = "Reading file %s";elsefmt = "Writing file %s";...// much laterCString s;s.Format(fmt,filename);// 使用資源串表之後，程式這樣寫：CString fmt;if(...)fmt.LoadString(IDS_READING_FILE);elsefmt.LoadString(DS_WRITING_FILE);...// much laterCString s;s.Format(fmt,filename);

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

CString s;s.LoadString(IDS_WHATEVER);CString t((LPCTSTR)IDS_WHATEVER);ASSERT(s == t);//不會被觸發，說明s和t是相同的。

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

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

CString s;s.LoadString(IDS_WHATEVER);CString t(MAKEINTRESOURCE(IDS_WHATEVER));ASSERT(s == t);

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

臨時對象

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

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

char* szName = GetName().GetBuffer(20)；RegSetValueEx(hKey,"Name",0,REG_SZ,(CONST BYTE *)szName,strlen(szName + 1));

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

真讓人困惑，請幫幫我。

親愛的 Frustrated，

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

CString Name = GetName();RegSetValueEx(hKey,_T("Name"),0,REG_SZ,(CONST BYTE *)(LPCTSTR)Name,(Name.GetLength()+ 1) * sizeof(TCHAR));

為什麼我寫的代碼能行而你寫的就有問題呢？主要是因為當你調用 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 的一個問題是它確實掩藏了一些低效率的東西。從另外一個方面講，它也確實可以被實現得更加高效，你可能會說下面的代碼：

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

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

char s[1024];lstrcpy(s,SomeString1);lstrcat(s,SomeString2);lstrcat(s,SomeString3);lstrcat(s,",");lstrcat(s,SomeString4);

總之，你可能會想，首先，它為 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 沒有很明顯的指出這些特徵，需要你自己去探索、去發現。