brucejini

CString 操作指南


原著：Joseph M. Newcomer

翻譯：littleloach

原文出處：codeproject：CString Management


通過閱讀本文你可以學(xué)習(xí)如何有效地使用 CString。

　　CString 是一種很有用的數(shù)據(jù)類型。它們很大程度上簡化了MFC中的許多操作，使得MFC在做字符串操作的時(shí)候方便了很多。不管怎樣，使用CString有很多特殊的技巧，特別是對于純C背景下走出來的程序員來說有點(diǎn)難以學(xué)習(xí)。這篇文章就來討論這些技巧。
　　使用CString可以讓你對字符串的操作更加直截了當(dāng)。這篇文章不是CString的完全手冊，但囊括了大部分常見基本問題。

這篇文章包括以下內(nèi)容：

1. CString 對象的連接

2. 格式化字符串（包括 int 型轉(zhuǎn)化為 CString ）
3. CString 型轉(zhuǎn)化成 int 型
4. CString 型和 char* 類型的相互轉(zhuǎn)化
   
   char* 轉(zhuǎn)化成 CString
   CString 轉(zhuǎn)化成 char* 之一：使用LPCTSTR強(qiáng)制轉(zhuǎn)化
   CString 轉(zhuǎn)化成 char* 之二：使用CString對象的GetBuffer方法
   CString 轉(zhuǎn)化成 char* 之三: 和控件的接口
5. CString 型轉(zhuǎn)化成 BSTR 型；
6. BSTR 型轉(zhuǎn)化成 CString 型；
7. VARIANT 型轉(zhuǎn)化成 CString 型；
8. 載入字符串表資源；
9. CString 和臨時(shí)對象；
10. CString 的效率；
11. 總結(jié)

下面我分別討論。

1、CString 對象的連接

　　能體現(xiàn)出 CString 類型方便性特點(diǎn)的一個(gè)方面就字符串的連接，使用 CString 類型，你能很方便地連接兩個(gè)字符串，正如下面的例子：

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

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

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

2、格式化字符串

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

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

　　用這種方法的好處是你不用擔(dān)心用來存放格式化后數(shù)據(jù)的緩沖區(qū)是否足夠大，這些工作由CString類替你完成。
　　格式化是一種把其它不是字符串類型的數(shù)據(jù)轉(zhuǎn)化為CString類型的最常用技巧，比如，把一個(gè)整數(shù)轉(zhuǎn)化成CString類型，可用如下方法：

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

　　我總是對我的字符串使用_T()宏，這是為了讓我的代碼至少有Unicode的意識(shí)，當(dāng)然，關(guān)于Unicode的話題不在這篇文章的討論范圍。_T()宏在8位字符環(huán)境下是如下定義的：

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

而在Unicode環(huán)境下是如下定義的：

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

所以在Unicode環(huán)境下，它的效果就相當(dāng)于：

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

　　如果你認(rèn)為你的程序可能在Unicode的環(huán)境下運(yùn)行，那么開始在意用 Unicode 編碼。比如說，不要用 sizeof() 操作符來獲得字符串的長度，因?yàn)樵赨nicode環(huán)境下就會(huì)有2倍的誤差。我們可以用一些方法來隱藏Unicode的一些細(xì)節(jié)，比如在我需要獲得字符長度的時(shí)候，我會(huì)用一個(gè)叫做DIM的宏，這個(gè)宏是在我的dim.h文件中定義的，我會(huì)在我寫的所有程序中都包含這個(gè)文件：

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

class Whatever { ... };
Whatever data[] = {
   { ... },
    ...
   { ... },
};
for(int i = 0; i < DIM(data); i++) // 掃描表格尋找匹配項(xiàng)。

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

造成以上原因是因?yàn)閘strcpyn需要一個(gè)字符個(gè)數(shù)作為參數(shù)，但是WriteFile卻需要字節(jié)數(shù)作為參數(shù)。
同樣需要注意的是有時(shí)候需要寫出數(shù)據(jù)的所有內(nèi)容。如果你僅僅只想寫出數(shù)據(jù)的真實(shí)長度，你可能會(huì)認(rèn)為你應(yīng)該這樣做：

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

但是在Unicode環(huán)境下，它不會(huì)正常工作。正確的做法應(yīng)該是這樣：

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

　　因?yàn)閃riteFile需要的是一個(gè)以字節(jié)為單位的長度。（可能有些人會(huì)想“在非Unicode的環(huán)境下運(yùn)行這行代碼，就意味著總是在做一個(gè)多余的乘1操作，這樣不會(huì)降低程序的效率嗎？”這種想法是多余的，你必須要了解編譯器實(shí)際上做了什么，沒有哪一個(gè)C或C++編譯器會(huì)把這種無聊的乘1操作留在代碼中。在Unicode環(huán)境下運(yùn)行的時(shí)候，你也不必?fù)?dān)心那個(gè)乘2操作會(huì)降低程序的效率，記住，這只是一個(gè)左移一位的操作而已，編譯器也很樂意為你做這種替換。）
　　使用_T宏并不是意味著你已經(jīng)創(chuàng)建了一個(gè)Unicode的程序，你只是創(chuàng)建了一個(gè)有Unicode意識(shí)的程序而已。如果你在默認(rèn)的8-bit模式下編譯你的程序的話，得到的將是一個(gè)普通的8-bit的應(yīng)用程序（這里的8-bit指的只是8位的字符編碼，并不是指8位的計(jì)算機(jī)系統(tǒng)）；當(dāng)你在Unicode環(huán)境下編譯你的程序時(shí)，你才會(huì)得到一個(gè)Unicode的程序。記住，CString 在 Unicode 環(huán)境下，里面包含的可都是16位的字符哦。

3、CString 型轉(zhuǎn)化成 int 型

　　把 CString 類型的數(shù)據(jù)轉(zhuǎn)化成整數(shù)類型最簡單的方法就是使用標(biāo)準(zhǔn)的字符串到整數(shù)轉(zhuǎn)換例程。
　　雖然通常你懷疑使用_atoi()函數(shù)是一個(gè)好的選擇，它也很少會(huì)是一個(gè)正確的選擇。如果你準(zhǔn)備使用 Unicode 字符，你應(yīng)該用_ttoi()，它在 ANSI 編碼系統(tǒng)中被編譯成_atoi()，而在 Unicode 編碼系統(tǒng)中編譯成_wtoi()。你也可以考慮使用_tcstoul()或者_(dá)tcstol()，它們都能把字符串轉(zhuǎn)化成任意進(jìn)制的長整數(shù)（如二進(jìn)制、八進(jìn)制、十進(jìn)制或十六進(jìn)制），不同點(diǎn)在于前者轉(zhuǎn)化后的數(shù)據(jù)是無符號(hào)的（unsigned），而后者相反?？聪旅娴睦樱?/p>

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

4、CString 型和 char* 類型的相互轉(zhuǎn)化

　　這是初學(xué)者使用 CString 時(shí)最常見的問題。有了 C++ 的幫助，很多問題你不需要深入的去考慮它，直接拿來用就行了，但是如果你不能深入了解它的運(yùn)行機(jī)制，又會(huì)有很多問題讓你迷惑，特別是有些看起來沒有問題的代碼，卻偏偏不能正常工作。
比如，你會(huì)奇怪為什么不能寫向下面這樣的代碼呢：

CString graycat = "Gray" + "Cat";

或者這樣：

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

　　事實(shí)上，編譯器將抱怨上面的這些嘗試。為什么呢？因?yàn)獒槍String 和 LPCTSTR數(shù)據(jù)類型的各種各樣的組合，“ +” 運(yùn)算符 被定義成一個(gè)重載操作符。而不是兩個(gè) LPCTSTR 數(shù)據(jù)類型，它是底層數(shù)據(jù)類型。你不能對基本數(shù)據(jù)（如 int、char 或者 char*）類型重載 C++ 的運(yùn)算符。你可以象下面這樣做：

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

或者這樣：

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

研究一番就會(huì)發(fā)現(xiàn)：“ +”總是使用在至少有一個(gè) CString 對象和一個(gè) LPCSTR 的場合。

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

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

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

char* 轉(zhuǎn)化為 CString

　　現(xiàn)在你有一個(gè) char* 類型的數(shù)據(jù)，或者說一個(gè)字符串。怎么樣創(chuàng)建 CString 對象呢？這里有一些例子：

char * p = "This is a test";

或者象下面這樣更具有 Unicode 意識(shí)：

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

或

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

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

CString s = "This is a test"; // 8-bit only
CString s = _T("This is a test"); // Unicode-aware
CString s("This is a test"); // 8-bit only
CString s(_T("This is a test")); // Unicode-aware
CString s = p;
CString s(p);

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

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

結(jié)果字符串肯定是“GrayCat”。

CString 類還有幾個(gè)其它的構(gòu)造函數(shù)，但是這里我們不考慮它，如果你有興趣可以自己查看相關(guān)文檔。

事實(shí)上，CString 類的構(gòu)造函數(shù)比我展示的要復(fù)雜，比如：

CString s = "This is a test"; 

　　這是很草率的編碼，但是實(shí)際上它在 Unicode 環(huán)境下能編譯通過。它在運(yùn)行時(shí)調(diào)用構(gòu)造函數(shù)的 MultiByteToWideChar 操作將 8 位字符串轉(zhuǎn)換成 16 位字符串。不管怎樣，如果 char * 指針是網(wǎng)絡(luò)上傳輸?shù)?8 位數(shù)據(jù)，這種轉(zhuǎn)換是很有用的。

CString 轉(zhuǎn)化成 char* 之一：強(qiáng)制類型轉(zhuǎn)換為 LPCTSTR；

　　這是一種略微硬性的轉(zhuǎn)換，有關(guān)“正確”的做法，人們在認(rèn)識(shí)上還存在許多混亂，正確的使用方法有很多，但錯(cuò)誤的使用方法可能與正確的使用方法一樣多。
　　我們首先要了解 CString 是一種很特殊的 C++ 對象，它里面包含了三個(gè)值：一個(gè)指向某個(gè)數(shù)據(jù)緩沖區(qū)的指針、一個(gè)是該緩沖中有效的字符記數(shù)以及一個(gè)緩沖區(qū)長度。 有效字符數(shù)的大小可以是從0到該緩沖最大長度值減1之間的任何數(shù)（因?yàn)樽址Y(jié)尾有一個(gè)NULL字符）。字符記數(shù)和緩沖區(qū)長度被巧妙隱藏。
　　除非你做一些特殊的操作，否則你不可能知道給CString對象分配的緩沖區(qū)的長度。這樣，即使你獲得了該0緩沖的地址，你也無法更改其中的內(nèi)容，不能截短字符串，也 絕對沒有辦法加長它的內(nèi)容，否則第一時(shí)間就會(huì)看到溢出。
　　LPCTSTR 操作符（或者更明確地說就是 TCHAR * 操作符）在 CString 類中被重載了，該操作符的定義是返回緩沖區(qū)的地址，因此，如果你需要一個(gè)指向 CString 的 字符串指針的話，可以這樣做：

CString s("GrayCat");
LPCTSTR p = s;

　　它可以正確地運(yùn)行。這是由C語言的強(qiáng)制類型轉(zhuǎn)化規(guī)則實(shí)現(xiàn)的。當(dāng)需要強(qiáng)制類型轉(zhuǎn)化時(shí)，C++規(guī)測容許這種選擇。比如，你可以將（浮點(diǎn)數(shù)）定義為將某個(gè)復(fù)數(shù) （有一對浮點(diǎn)數(shù)）進(jìn)行強(qiáng)制類型轉(zhuǎn)換后只返回該復(fù)數(shù)的第一個(gè)浮點(diǎn)數(shù)（也就是其實(shí)部）?？梢韵笙旅孢@樣：

Complex c(1.2f, 4.8f);
float realpart = c;

如果(float)操作符定義正確的話，那么實(shí)部的的值應(yīng)該是1.2。
　　這種強(qiáng)制轉(zhuǎn)化適合所有這種情況，例如，任何帶有 LPCTSTR 類型參數(shù)的函數(shù)都會(huì)強(qiáng)制執(zhí)行這種轉(zhuǎn)換。 于是，你可能有這樣一個(gè)函數(shù)（也許在某個(gè)你買來的DLL中）：

BOOL DoSomethingCool(LPCTSTR s);

你象下面這樣調(diào)用它：

CString file("c:\\myfiles\\coolstuff")
BOOL result = DoSomethingCool(file);

　　它能正確運(yùn)行。因?yàn)?DoSomethingCool 函數(shù)已經(jīng)說明了需要一個(gè) LPCTSTR 類型的參數(shù)，因此 LPCTSTR 被應(yīng)用于該參數(shù)，在 MFC 中就是返回的串地址。

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

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

　　注意由于在可變參數(shù)列表中的值（在函數(shù)說明中是以“...”表示的）并沒有隱含一個(gè)強(qiáng)制類型轉(zhuǎn)換操作符。你會(huì)得到什么結(jié)果呢？
　　一個(gè)令人驚訝的結(jié)果，我們得到的實(shí)際結(jié)果串是：

"Mew! I love GrayCat"。

　　因?yàn)?MFC 的設(shè)計(jì)者們在設(shè)計(jì) CString 數(shù)據(jù)類型時(shí)非常小心， CString 類型表達(dá)式求值后指向了字符串，所以這里看不到任何象 Format 或 sprintf 中的強(qiáng)制類型轉(zhuǎn)換，你仍然可以得到正確的行為。描述 CString 的附加數(shù)據(jù)實(shí)際上在 CString 名義地址之后。
　　有一件事情你是不能做的，那就是修改字符串。比如，你可能會(huì)嘗試用“,”代替“.”（不要做這樣的，如果你在乎國際化問題，你應(yīng)該使用十進(jìn)制轉(zhuǎn)換的 National Language Support 特性，），下面是個(gè)簡單的例子：

CString v("1.00"); // 貨幣金額，兩位小數(shù)
LPCTSTR p = v;
p[lstrlen(p) - 3] = '','';

　　這時(shí)編譯器會(huì)報(bào)錯(cuò)，因?yàn)槟阗x值了一個(gè)常量串。如果你做如下嘗試，編譯器也會(huì)錯(cuò)：

strcat(p, "each");

　　因?yàn)?strcat 的第一個(gè)參數(shù)應(yīng)該是 LPTSTR 類型的數(shù)據(jù)，而你卻給了一個(gè) LPCTSTR。

　　不要試圖鉆這個(gè)錯(cuò)誤消息的牛角尖，這只會(huì)使你自己陷入麻煩！

　　原因是緩沖有一個(gè)計(jì)數(shù)，它是不可存取的（它位于 CString 地址之下的一個(gè)隱藏區(qū)域），如果你改變這個(gè)串，緩沖中的字符計(jì)數(shù)不會(huì)反映所做的修改。此外，如果字符串長度恰好是該字符串物理限制的長度（梢后還會(huì)講到這個(gè)問題），那么擴(kuò)展該字符串將改寫緩沖以外的任何數(shù)據(jù)，那是你無權(quán)進(jìn)行寫操作的內(nèi)存（不對嗎？），你會(huì)毀換壞不屬于你的內(nèi)存。這是應(yīng)用程序真正的死亡處方。

CString轉(zhuǎn)化成char* 之二：使用 CString 對象的 GetBuffer 方法；

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

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 的第一種用法，也是最簡單的一種，不用給它傳遞參數(shù)，它使用默認(rèn)值 0，意思是：“給我這個(gè)字符串的指針，我保證不加長它”。當(dāng)你調(diào)用 ReleaseBuffer 時(shí)，字符串的實(shí)際長度會(huì)被重新計(jì)算，然后存入 CString 對象中。
　　必須強(qiáng)調(diào)一點(diǎn)，在 GetBuffer 和 ReleaseBuffer 之間這個(gè)范圍，一定不能使用你要操作的這個(gè)緩沖的 CString 對象的任何方法。因?yàn)?ReleaseBuffer 被調(diào)用之前，該 CString 對象的完整性得不到保障。研究以下代碼：

CString s(...);

LPTSTR p = s.GetBuffer();

//... 這個(gè)指針 p 發(fā)生了很多事情

int n = s.GetLength(); // 很糟D!!!!! 有可能給出錯(cuò)誤的答案!!!

s.TrimRight(); // 很糟!!!!! 不能保證能正常工作!!!!

s.ReleaseBuffer(); // 現(xiàn)在應(yīng)該 OK

int m = s.GetLength(); // 這個(gè)結(jié)果可以保證是正確的。

s.TrimRight(); // 將正常工作。

　　假設(shè)你想增加字符串的長度，你首先要知道這個(gè)字符串可能會(huì)有多長，好比是聲明字符串?dāng)?shù)組的時(shí)候用：

char buffer[1024];

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

LPTSTR p = s.GetBuffer(1024);

　　調(diào)用這個(gè)函數(shù)后，你不僅獲得了字符串緩沖區(qū)的指針，而且同時(shí)還獲得了長度至少為 1024 個(gè)字符的空間（注意，我說的是“字符”，而不是“字節(jié)”，因?yàn)?CString 是以隱含方式感知 Unicode 的）。
　　同時(shí)，還應(yīng)該注意的是，如果你有一個(gè)常量串指針，這個(gè)串本身的值被存儲(chǔ)在只讀內(nèi)存中，如果試圖存儲(chǔ)它，即使你已經(jīng)調(diào)用了 GetBuffer ，并獲得一個(gè)只讀內(nèi)存的指針，存入操作會(huì)失敗，并報(bào)告存取錯(cuò)誤。我沒有在 CString 上證明這一點(diǎn)，但我看到過大把的 C 程序員經(jīng)常犯這個(gè)錯(cuò)誤。
　　C 程序員有一個(gè)通病是分配一個(gè)固定長度的緩沖，對它進(jìn)行 sprintf 操作，然后將它賦值給一個(gè) CString：

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

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

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

如果你的字符串長度萬一超過 256 個(gè)字符的時(shí)候，不會(huì)破壞堆棧。

　　另外一個(gè)常見的錯(cuò)誤是：既然固定大小的內(nèi)存不工作，那么就采用動(dòng)態(tài)分配字節(jié)，這種做法弊端更大：

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() 來包圍格式化字符串，但是基本 思路仍然是在走彎路，這這樣很容易出錯(cuò)。

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

　　我們經(jīng)常需要把一個(gè) CString 的值傳遞給一個(gè)控件，比如，CTreeCtrl。MFC為我們提供了很多便利來重載這個(gè)操作，但是 在大多數(shù)情況下，你使用“原始”形式的更新，因此需要將墨某個(gè)串指針存儲(chǔ)到 TVINSERTITEMSTRUCT 結(jié)構(gòu)的 TVITEM 成員中。如下：

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

　　為什么編譯器會(huì)報(bào)錯(cuò)呢？明明看起來很完美的用法??！但是事實(shí)上如果你看看 TVITEM 結(jié)構(gòu)的定義你就會(huì)明白，在 TVITEM 結(jié)構(gòu)中 pszText 成員的聲明如下：

LPTSTR pszText;
int cchTextMax;

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

tvi.item.pszText = (LPCTSTR)s; //編譯器依然會(huì)報(bào)錯(cuò)。

　　編譯器之所以依然報(bào)錯(cuò)是因?yàn)槟阍噲D把一個(gè) LPCTSTR 類型的變量賦值給一個(gè) LPTSTR 類型的變量，這種操作在C或C++中是被禁止的。你不能用這種方法 來濫用常量指針與非常量指針概念，否則，會(huì)擾亂編譯器的優(yōu)化機(jī)制，使之不知如何優(yōu)化你的程序。比如，如果你這么做：

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

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

const int i = ...;
int * p = &i;
//... do lots of stuff
... = a[i]; // usage 1
// ... lots more stuff
(*p)++; // mess over compiler''s assumption
// ... and other stuff
... = a[i]; // usage 2

　　編譯器將認(rèn)為 i 是常量，從而 a[i] 的位置也是常量，這樣間接地破壞了先前的假設(shè)。因此，你的程序?qū)?huì)在 debug 編譯模式（沒有優(yōu)化）和 release 編譯模式（完全優(yōu)化）中反映出不同的行為，這種情況可不好，所以當(dāng)你試圖把指向 i 的指針賦值給一個(gè) 可修改的引用時(shí)，會(huì)被編譯器診斷為這是一種偽造。這就是為什么（LPCTSTR）強(qiáng)制類型轉(zhuǎn)化不起作用的原因。
　　為什么不把該成員聲明成 LPCTSTR 類型呢？因?yàn)檫@個(gè)結(jié)構(gòu)被用于讀寫控件。當(dāng)你向控件寫數(shù)據(jù)時(shí)，文本指針實(shí)際上被當(dāng)成 LPCTSTR，而當(dāng)你從控件讀數(shù)據(jù) 時(shí)，你必須有一個(gè)可寫的字符串。這個(gè)結(jié)構(gòu)無法區(qū)分它是用來讀還是用來寫。

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

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

　　它把 CString 強(qiáng)制類型轉(zhuǎn)化成 LPCTSTR，也就是說先獲得改字符串的地址，然后再強(qiáng)制類型轉(zhuǎn)化成 LPTSTR，以便可以對之進(jìn)行賦值操作。 注意這只有在使用 Set 或 Insert 之類的方法才有效！如果你試圖獲取數(shù)據(jù)，則不能這么做。
　　如果你打算獲取存儲(chǔ)在控件中的數(shù)據(jù)，則方法稍有不同，例如，對某個(gè) CTreeCtrl 使用 GetItem 方法，我想獲取項(xiàng)目的文本。我知道這些 文本的長度不會(huì)超過 MY_LIMIT，因此我可以這樣寫：

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

　　可以看出來，其實(shí)上面的代碼對所有類型的 Set 方法都適用，但是并不需要這么做，因?yàn)樗械念?Set 方法（包括 Insert方法）不會(huì)改變字符串的內(nèi)容。但是當(dāng)你需要寫 CString 對象時(shí)，必須保證緩沖是可寫的，這正是 GetBuffer 所做的事情。再次強(qiáng)調(diào)： 一旦做了一次 GetBuffer 調(diào)用，那么在調(diào)用 ReleaseBuffer 之前不要對這個(gè) CString 對象做任何操作。

5、CString 型轉(zhuǎn)化成 BSTR 型

　　當(dāng)我們使用 ActiveX 控件編程時(shí)，經(jīng)常需要用到將某個(gè)值表示成 BSTR 類型。BSTR 是一種記數(shù)字符串，Intel平臺(tái)上的寬字符串（Unicode），并且 可以包含嵌入的 NULL 字符。

你可以調(diào)用 CString 對象的 AllocSysString 方法將 CString 轉(zhuǎn)化成 BSTR：

CString s;
s = ... ; // whatever
BSTR b = s.AllocSysString();

　　現(xiàn)在指針 b 指向的就是一個(gè)新分配的 BSTR 對象，該對象是 CString 的一個(gè)拷貝，包含終結(jié) NULL字符。現(xiàn)在你可以將它傳遞給任何需要 BSTR 的接口。通常，BSTR 由接收它的組件來釋放，如果你需要自己釋放 BSTR 的話，可以這么做：

::SysFreeString(b);

　　對于如何表示傳遞給 ActiveX 控件的字符串，在微軟內(nèi)部曾一度爭論不休，最后 Visual Basic 的人占了上風(fēng)，BSTR（“Basic String”的首字母縮寫）就是這場爭論的結(jié)果。

6、BSTR 型轉(zhuǎn)化成 CString 型

　　由于 BSTR 是記數(shù) Unicode 字符串，你可以用標(biāo)準(zhǔn)轉(zhuǎn)換方法來創(chuàng)建 8 位的 CString。實(shí)際上，這是 CString 內(nèi)建的功能。在 CString 中 有特殊的構(gòu)造函數(shù)可以把 ANSI 轉(zhuǎn)化成 Unicode，也可以把Unicode 轉(zhuǎn)化成 ANSI。你同樣可以從 VARIANT 類型的變量中獲得 BSTR 類型的字符串，VARIANT 類型是 由各種 COM 和 Automation (自動(dòng)化)調(diào)用返回的類型。

例如，在一個(gè)ANSI程序中：

BSTR b;
b = ...; // whatever
CString s(b == NULL ? L"" : b)

　　對于單個(gè)的 BSTR 串來說，這種用法可以工作得很好，這是因?yàn)?CString 有一個(gè)特殊的構(gòu)造函數(shù)以LPCWSTR（BSTR正是這種類型） 為參數(shù)，并將它轉(zhuǎn)化成 ANSI 類型。專門檢查是必須的，因?yàn)?BSTR 可能為空值，而 CString 的構(gòu)造函數(shù)對于 NULL 值情況考慮的不是很周到，（感謝 Brian Ross 指出這一點(diǎn)!）。這種用法也只能處理包含 NUL 終結(jié)字符的單字符串；如果要轉(zhuǎn)化含有多個(gè) NULL 字符 串，你得額外做一些工作才行。在 CString 中內(nèi)嵌的 NULL 字符通常表現(xiàn)不盡如人意，應(yīng)該盡量避免。
　　根據(jù) C/C++ 規(guī)則，如果你有一個(gè) LPWSTR，那么它別無選擇，只能和 LPCWSTR 參數(shù)匹配。

在 Unicode 模式下，它的構(gòu)造函數(shù)是：

CString::CString(LPCTSTR);

正如上面所表示的，在 ANSI 模式下，它有一個(gè)特殊的構(gòu)造函數(shù)：

CString::CString(LPCWSTR); 

　　它會(huì)調(diào)用一個(gè)內(nèi)部的函數(shù)將 Unicode 字符串轉(zhuǎn)換成 ANSI 字符串。（在Unicode模式下，有一個(gè)專門的構(gòu)造函數(shù)，該函數(shù)有一個(gè)參數(shù)是LPCSTR類型——一個(gè)8位 ANSI 字符串 指針，該函數(shù)將它加寬為 Unicode 的字符串！）再次強(qiáng)調(diào)：一定要檢查 BSTR 的值是否為 NULL。
　　另外還有一個(gè)問題，正如上文提到的：BSTRs可以含有多個(gè)內(nèi)嵌的NULL字符，但是 CString 的構(gòu)造函數(shù)只能處理某個(gè)串中單個(gè) NULL 字符。 也就是說，如果串中含有嵌入的 NUL字節(jié)，CString 將會(huì)計(jì)算出錯(cuò)誤的串長度。你必須自己處理它。如果你看看 strcore.cpp 中的構(gòu)造函數(shù)，你會(huì)發(fā)現(xiàn) 它們都調(diào)用了lstrlen，也就是計(jì)算字符串的長度。
　　注意從 Unicode 到 ANSI 的轉(zhuǎn)換使用帶專門參數(shù)的 ::WideCharToMultiByte，如果你不想使用這種默認(rèn)的轉(zhuǎn)換方式，則必須編寫自己的轉(zhuǎn)化代碼。
　　如果你在 UNICODE 模式下編譯代碼，你可以簡單地寫成：

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

CString convert(BSTR b)
{
    CString s;
    if(b == NULL)
       return s; // empty for NULL BSTR
#ifdef UNICODE
    s = b;
#else
    LPSTR p = s.GetBuffer(SysStringLen(b) + 1); 
    ::WideCharToMultiByte(CP_ACP,            // ANSI Code Page
                          0,                 // no flags
                          b,                 // source widechar string
                          -1,                // assume NUL-terminated
                          p,                 // target buffer
                          SysStringLen(b)+1, // target buffer length
                          NULL,              // use system default char
                          NULL);             // don''t care if default used
    s.ReleaseBuffer();
#endif
    return s;
}

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

你還可以根據(jù) vt 域的不同來建立更通用的轉(zhuǎn)換例程。為此你可能會(huì)考慮：

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;
       ... 剩下的類型轉(zhuǎn)換由讀者自己完成
       default:
          ASSERT(FALSE); // unknown VARIANT type (this ASSERT is optional)
          return CString("");
      } /* vt */
}

CString s = "There is an error";

　　你應(yīng)該把你所有特定語言的字符串單獨(dú)擺放（調(diào)試信息、在發(fā)布版本中不出現(xiàn)的信息除外）。這意味著向下面這樣寫比較好：

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

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

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

　　這是我的切身體會(huì)。在我的第一個(gè)國際化的應(yīng)用程序中我犯了這個(gè)錯(cuò)誤，盡管我懂德語，知道在德語的語法中動(dòng)詞放在句子的最后面，我們的德國方面的發(fā)行人還是苦苦的抱怨他們不得不提取那些不可思議的德語錯(cuò)誤提示信息然后重新格式化以讓它們能正常工作。比較好的辦法（也是我現(xiàn)在使用的辦法）是使用兩個(gè)字符串，一個(gè)用 于讀，一個(gè)用于寫，在使用時(shí)加載合適的版本，使得它們對字符串參數(shù)是非敏感的。也就是說加載整個(gè)格式，而不是加載串“reading”，“writing”：

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

　　一定要注意，如果你有好幾個(gè)地方需要替換，你一定要保證替換后句子的結(jié)構(gòu)不會(huì)出現(xiàn)問題，比如在英語中，可以是主語-賓語，主語-謂語，動(dòng)詞-賓語的結(jié)構(gòu)等等。
　　在這里，我們并不討論 FormatMessage，其實(shí)它比 sprintf/Format 還要有優(yōu)勢，但是不太容易和CString 結(jié)合使用。解決這種問題的辦法就是我們按照參數(shù)出現(xiàn)在參數(shù)表中的位置給參數(shù)取名字，這樣在你輸出的時(shí)候就不會(huì)把他們的位置排錯(cuò)了。
　　接下來我們討論我們這些獨(dú)立的字符串放在什么地方。我們可以把字符串的值放入資源文件中的一個(gè)稱為 STRINGTABLE 的段中。過程如下：首先使用 Visual Studio 的資源編輯器創(chuàng)建一個(gè)字符串，然后給每一個(gè)字符串取一個(gè)ID，一般我們給它取名字都以 IDS_開頭。所以如果你有一個(gè)信息，你可以創(chuàng)建一個(gè)字符串資源然后取名為 IDS_READING_FILE，另外一個(gè)就取名為 IDS_WRITING_FILE。它們以下面的形式出現(xiàn)在你的 .rc 文件中：

STRINGTABLE
IDS_READING_FILE "Reading file %s"
IDS_WRITING_FILE "Writing file %s"
END

注意：這些資源都以 Unicode 的格式保存，不管你是在什么環(huán)境下編譯。他們在Win9x系統(tǒng)上也是以Unicode 的形式存在，雖然 Win9x 不能真正處理 Unicode。
然后你可以這樣使用這些資源：
// 在使用資源串表之前，程序是這樣寫的：

   CString fmt;
      if(...)
        fmt = "Reading file %s";
     else
       fmt = "Writing file %s";
  ...
    // much later
  CString s;
  s.Format(fmt, filename); 

    CString fmt;
        if(...)
           fmt.LoadString(IDS_READING_FILE);
        else
           fmt.LoadString(DS_WRITING_FILE);
    ...
      // much later
    CString s;
    s.Format(fmt, filename);

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

　　現(xiàn)在，你可能會(huì)想：這怎么可能工作呢？我們怎么能把 STRINGTABLE ID 轉(zhuǎn)化成一個(gè)指針呢？很簡單：所有的字符串 ID 都在1~65535這個(gè)范圍內(nèi)，也就是說，它所有的高位都是0，而我們在程序中所使用的指針是不可能小于65535的，因?yàn)槌绦虻牡?64K 內(nèi)存永遠(yuǎn)也不可能存在的，如果你試圖訪問0x00000000到0x0000FFFF之間的內(nèi)存，將會(huì)引發(fā)一個(gè)內(nèi)存越界錯(cuò)誤。所以說1~65535的值不可能是一個(gè)內(nèi)存地址，所以我們可以用這些值來作為字符串資源的ID。
　　我傾向于使用 MAKEINTRESOURCE 宏顯式地做這種轉(zhuǎn)換。我認(rèn)為這樣可以讓代碼更加易于閱讀。這是個(gè)只適合在 MFC 中使用的標(biāo)準(zhǔn)宏。你要記住，大多數(shù)的方法即可以接受一個(gè) UINT 型的參數(shù)，也可以接受一個(gè) LPCTSTR 型的參數(shù)，這是依賴 C++ 的重載功能做到的。C++重載函數(shù)帶來的 弊端就是造成所有的強(qiáng)制類型轉(zhuǎn)化都需要顯示聲明。同樣，你也可以給很多種結(jié)構(gòu)只傳遞一個(gè)資源名。

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

　　告訴你吧：我不僅只是在這里鼓吹，事實(shí)上我也是這么做的。在我的代碼中，你幾乎不可能找到一個(gè)字符串，當(dāng)然，那些只是偶然在調(diào)試中出現(xiàn)的或者和語言無關(guān)的字符串除外。

9、CString 和臨時(shí)對象

　　這是出現(xiàn)在 microsoft.public.vc.mfc 新聞組中的一個(gè)小問題，我簡單的提一下，這個(gè)問題是有個(gè)程序員需要往注冊表中寫入一個(gè)字符串，他寫道：
　　我試著用 RegSetValueEx() 設(shè)置一個(gè)注冊表鍵的值，但是它的結(jié)果總是令我困惑。當(dāng)我用char[]聲明一個(gè)變量時(shí)它能正常工作，但是當(dāng)我用 CString 的時(shí)候，總是得到一些垃圾："ÝÝÝÝ...ÝÝÝÝÝÝ"為了確認(rèn)是不是我的 CString 數(shù)據(jù)出了問題，我試著用 GetBuffer，然后強(qiáng)制轉(zhuǎn)化成 char*，LPCSTR。GetBuffer 返回的值是正確的，但是當(dāng)我把它賦值給 char* 時(shí)，它就變成垃圾了。以下是我的程序段：

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

這個(gè) Name 字符串的長度小于 20，所以我不認(rèn)為是 GetBuffer 的參數(shù)的問題。

真讓人困惑，請幫幫我。

親愛的 Frustrated，

你犯了一個(gè)相當(dāng)微妙的錯(cuò)誤，聰明反被聰明誤，正確的代碼應(yīng)該象下面這樣：

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

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

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

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

　　總之，你可能會(huì)想，首先，它為 SomeCString1 分配一塊內(nèi)存，然后把 SomeCString1 復(fù)制到里面，然后發(fā)現(xiàn)它要做一個(gè)連接，則重新分配一塊新的足夠大的內(nèi)存，大到能夠放下當(dāng)前的字符串加上SomeCString2，把內(nèi)容復(fù)制到這塊內(nèi)存 ，然后把 SomeCString2 連接到后面，然后釋放第一塊內(nèi)存，并把指針重新指向新內(nèi)存。然后為每個(gè)字符串重復(fù)這個(gè)過程。把這 4 個(gè)字符串連接起來效率多低啊。事實(shí)上，在很多情況下根本就不需要復(fù)制源字符串（在 += 操作符左邊的字符串）。
　　在 VC++6.0 中，Release 模式下，所有的 CString 中的緩存都是按預(yù)定義量子分配的。所謂量子，即確定為 64、128、256 或者 512 字節(jié)。這意味著除非字符串非常長，連接字符串的操作實(shí)際上就是 strcat 經(jīng)過優(yōu)化后的版本（因?yàn)樗辣镜氐淖址畱?yīng)該在什么地方結(jié)束，所以不需要尋找字符串的結(jié)尾；只需要把內(nèi)存中的數(shù)據(jù)拷貝到指定的地方即可）加上重新計(jì)算字符串的長度。所以它的執(zhí)行效率和純 C 的代碼是一樣的，但是它更容易寫、更容易維護(hù)和更容易理解。
　　如果你還是不能確定究竟發(fā)生了怎樣的過程，請看看 CString 的源代碼，strcore.cpp，在你 vc98的安裝目錄的 mfc\src 子目錄中?？纯?ConcatInPlace 方法，它被在所有的 += 操作符中調(diào)用。

啊哈！難道 CString 真的這么"高效"嗎？比如，如果我創(chuàng)建

CString cat("Mew!");

　　然后我并不是得到了一個(gè)高效的、精簡的5個(gè)字節(jié)大小的緩沖區(qū)（4個(gè)字符加一個(gè)結(jié)束字符），系統(tǒng)將給我分配64個(gè)字節(jié)，而其中59個(gè)字節(jié)都被浪費(fèi)了。
　　如果你也是這么想的話，那么就請準(zhǔn)備好接受再教育吧?？赡茉谀硞€(gè)地方某個(gè)人給你講過盡量使用少的空間是件好事情。不錯(cuò)，這種說法的確正確，但是他忽略了事實(shí)中一個(gè)很重要的方面。
　　如果你編寫的是運(yùn)行在16K EPROMs下的嵌入式程序的話，你有理由盡量少使用空間，在這種環(huán)境下，它能使你的程序更健壯。但是在 500MHz, 256MB的機(jī)器上寫 Windows 程序，如果你還是這么做，它只會(huì)比你認(rèn)為的“低效”的代碼運(yùn)行得更糟。
　　舉例來說。字符串的大小被認(rèn)為是影響效率的首要因素，使字符串盡可能小可以提高效率，反之則降低效率，這是大家一貫的想法。但是這種想法是不對的，精確的內(nèi)存分配的后果要在程序運(yùn)行了好幾個(gè)小時(shí)后才能體現(xiàn)得出來，那時(shí)，程序的堆中將充滿小片的內(nèi)存，它們太小以至于不能用來做任何事，但是他們增加了你程序的內(nèi)存用量，增加了內(nèi)存頁面交換的次數(shù)，當(dāng)頁面交換的次數(shù)增加到系統(tǒng)能夠忍受的上限，系統(tǒng)則會(huì)為你的程序分配更多的頁面，直到你的程序占用了所有的可用內(nèi)存。由此可見，雖然內(nèi)存碎片是決定效率的次要因素，但正是這些因素實(shí)際控制了系統(tǒng)的行為，最終，它損害了系統(tǒng)的可靠性，這是令人無法接受的。
　　記住，在 debug 模式下，內(nèi)存往往是精確分配的，這是為了更好的排錯(cuò)。
　　假設(shè)你的應(yīng)用程序通常需要連續(xù)工作好幾個(gè)月。比如，我常打開 VC++，Word，PowerPoint，F(xiàn)rontpage，Outlook Express，F(xiàn)orté Agent，Internet Explorer和其它的一些程序，而且通常不關(guān)閉它們。我曾經(jīng)夜以繼日地連續(xù)用 PowerPoint 工作了好幾天（反之，如果你不幸不得不使用像 Adobe FrameMaker 這樣的程序的話，你將會(huì)體會(huì)到可靠性的重要；這個(gè)程序機(jī)會(huì)每天都要崩潰4~6次，每次都是因?yàn)橛猛炅怂械目臻g并填滿我所有的交換頁面）。所以精確內(nèi)存分配是不可取的，它會(huì)危及到系統(tǒng)的可靠性，并引起應(yīng)用程序崩潰。
　　按量子的倍數(shù)為字符串分配內(nèi)存，內(nèi)存分配器就可以回收用過的內(nèi)存塊，通常這些回收的內(nèi)存塊馬上就可以被其它的 CString 對象重新用到，這樣就可以保證碎片最少。分配器的功能加強(qiáng)了，應(yīng)用程序用到的內(nèi)存就能盡可能保持最小，這樣的程序就可以運(yùn)行幾個(gè)星期或幾個(gè)月而不出現(xiàn)問題。
　　題外話：很多年以前，我們在 CMU 寫一個(gè)交互式系統(tǒng)的時(shí)候，一些對內(nèi)存分配器的研究顯示出它往往產(chǎn)生很多內(nèi)存碎片。Jim Mitchell，現(xiàn)在他在 Sun Microsystems 工作，那時(shí)侯他創(chuàng)造了一種內(nèi)存分配器，它保留了一個(gè)內(nèi)存分配狀況的運(yùn)行時(shí)統(tǒng)計(jì)表，這種技術(shù)和當(dāng)時(shí)的主流分配器所用的技術(shù)都不同，且較為領(lǐng)先。當(dāng)一個(gè)內(nèi)存塊需要被分割得比某一個(gè)值小的話，他并不分割它，因此可以避免產(chǎn)生太多小到什么事都干不了的內(nèi)存碎片。事實(shí)上他在內(nèi)存分配器中使用了一個(gè)浮動(dòng)指針，他認(rèn)為：與其讓指令做長時(shí)間的存取內(nèi)存操作，還不如簡單的忽略那些太小的內(nèi)存塊而只做一些浮動(dòng)指針的操作。（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.）他是對的。
　　永遠(yuǎn)不要認(rèn)為所謂的“最優(yōu)化”是建立在每一行代碼都高速且節(jié)省內(nèi)存的基礎(chǔ)上的，事實(shí)上，高速且節(jié)省內(nèi)存應(yīng)該是在一個(gè)應(yīng)用程序的整體水平上考慮的。在軟件的整體水平上，只使用最小內(nèi)存的字符串分配策略可能是最糟糕的一種方法。
　　如果你認(rèn)為優(yōu)化是你在每一行代碼上做的那些努力的話，你應(yīng)該想一想：在每一行代碼中做的優(yōu)化很少能真正起作用。你可以看我的另一篇關(guān)于優(yōu)化問題的文章《Your Worst Enemy for some thought-provoking ideas》。
　　記住，+= 運(yùn)算符只是一種特例，如果你寫成下面這樣：

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

則每一個(gè) + 的應(yīng)用會(huì)造成一個(gè)新的字符串被創(chuàng)建和一次復(fù)制操作。

總結(jié)

　　以上是使用 CString 的一些技巧。我每天寫程序的時(shí)候都會(huì)用到這些。CString 并不是一種很難使用的類，但是 MFC 沒有很明顯的指出這些特征，需要你自己去探索、去發(fā)現(xiàn)。