CString 操作指南
原著：Joseph M. Newcomer
翻譯：littleloach
?
原文出處：codeproject：CString Management
通過閱讀本文你可以學(xué)習(xí)如何有效地使用 CString。
CString 是一種很有用的數(shù)據(jù)類型。它們很大程度上簡(jiǎn)化了MFC中的許多操作，使得MFC在做字符串操作的時(shí)候方便了很多。不管怎樣，使用CString有很多特殊的技巧，特別是對(duì)于純C背景下走出來(lái)的程序員來(lái)說(shuō)有點(diǎn)難以學(xué)習(xí)。這篇文章就來(lái)討論這些技巧。
使用CString可以讓你對(duì)字符串的操作更加直截了當(dāng)。這篇文章不是CString的完全手冊(cè)，但囊括了大部分常見基本問題。
這篇文章包括以下內(nèi)容：
CString 對(duì)象的連接
下面我分別討論。
1、CString 對(duì)象的連接
能體現(xiàn)出 CString 類型方便性特點(diǎn)的一個(gè)方面就字符串的連接，使用 CString 類型，你能很方便地連接兩個(gè)字符串，正如下面的例子：
要比用下面的方法好得多：
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ù)來(lái)格式化一個(gè)字符串，還不如用 CString 對(duì)象的Format()方法：
用這種方法的好處是你不用擔(dān)心用來(lái)存放格式化后數(shù)據(jù)的緩沖區(qū)是否足夠大，這些工作由CString類替你完成。
格式化是一種把其它不是字符串類型的數(shù)據(jù)轉(zhuǎn)化為CString類型的最常用技巧，比如，把一個(gè)整數(shù)轉(zhuǎn)化成CString類型，可用如下方法：
我總是對(duì)我的字符串使用_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 編碼。比如說(shuō)，不要用 sizeof() 操作符來(lái)獲得字符串的長(zhǎng)度，因?yàn)樵赨nicode環(huán)境下就會(huì)有2倍的誤差。我們可以用一些方法來(lái)隱藏Unicode的一些細(xì)節(jié)，比如在我需要獲得字符長(zhǎng)度的時(shí)候，我會(huì)用一個(gè)叫做DIM的宏，這個(gè)宏是在我的dim.h文件中定義的，我會(huì)在我寫的所有程序中都包含這個(gè)文件：
#define DIM(x) ( sizeof((x)) / sizeof((x)[0]) )這個(gè)宏不僅可以用來(lái)解決Unicode的字符串長(zhǎng)度的問題，也可以用在編譯時(shí)定義的表格上，它可以獲得表格的項(xiàng)數(shù)，如下：
class Whatever { ... }; Whatever data[] = {{ ... },...{ ... }, }; for(int i = 0; i < DIM(data); i++) // 掃描表格尋找匹配項(xiàng)。這里要提醒你的就是一定要注意那些在參數(shù)中需要真實(shí)字節(jié)數(shù)的API函數(shù)調(diào)用，如果你傳遞字符個(gè)數(shù)給它，它將不能正常工作。如下：
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í)長(zhǎng)度，你可能會(huì)認(rèn)為你應(yīng)該這樣做：
但是在Unicode環(huán)境下，它不會(huì)正常工作。正確的做法應(yīng)該是這樣：
WriteFile(f, data, lstrlen(data) * sizeof(TCHAR), &bytesWritten, NULL); // RIGHT 因?yàn)閃riteFile需要的是一個(gè)以字節(jié)為單位的長(zhǎng)度。（可能有些人會(huì)想“在非Unicode的環(huán)境下運(yùn)行這行代碼，就意味著總是在做一個(gè)多余的乘1操作，這樣不會(huì)降低程序的效率嗎？”這種想法是多余的，你必須要了解編譯器實(shí)際上做了什么，沒有哪一個(gè)C或C++編譯器會(huì)把這種無(wú)聊的乘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ù)類型最簡(jiǎn)單的方法就是使用標(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)制的長(zhǎng)整數(shù)（如二進(jìn)制、八進(jìn)制、十進(jìn)制或十六進(jìn)制），不同點(diǎn)在于前者轉(zhuǎn)化后的數(shù)據(jù)是無(wú)符號(hào)的（unsigned），而后者相反。看下面的例子：
4、CString 型和 char* 類型的相互轉(zhuǎn)化
這是初學(xué)者使用 CString 時(shí)最常見的問題。有了 C++ 的幫助，很多問題你不需要深入的去考慮它，直接拿來(lái)用就行了，但是如果你不能深入了解它的運(yùn)行機(jī)制，又會(huì)有很多問題讓你迷惑，特別是有些看起來(lái)沒有問題的代碼，卻偏偏不能正常工作。
比如，你會(huì)奇怪為什么不能寫向下面這樣的代碼呢：
或者這樣：
CString graycat("Gray" + "Cat");事實(shí)上，編譯器將抱怨上面的這些嘗試。為什么呢？因?yàn)獒槍?duì)CString 和 LPCTSTR數(shù)據(jù)類型的各種各樣的組合，“ +” 運(yùn)算符 被定義成一個(gè)重載操作符。而不是兩個(gè) LPCTSTR 數(shù)據(jù)類型，它是底層數(shù)據(jù)類型。你不能對(duì)基本數(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 對(duì)象和一個(gè) LPCSTR 的場(chǎng)合。
注意，編寫有 Unicode 意識(shí)的代碼總是一件好事，比如：
這將使得你的代碼可以直接移植。
char* 轉(zhuǎn)化為 CString
現(xiàn)在你有一個(gè) char* 類型的數(shù)據(jù)，或者說(shuō)一個(gè)字符串。怎么樣創(chuàng)建 CString 對(duì)象呢？這里有一些例子：
或者象下面這樣更具有 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 對(duì)象中去的，所以你可以象下面這樣操作：
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ù)雜，比如：
這是很草率的編碼，但是實(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)“正確”的做法，人們?cè)谡J(rèn)識(shí)上還存在許多混亂，正確的使用方法有很多，但錯(cuò)誤的使用方法可能與正確的使用方法一樣多。
我們首先要了解 CString 是一種很特殊的 C++ 對(duì)象，它里面包含了三個(gè)值：一個(gè)指向某個(gè)數(shù)據(jù)緩沖區(qū)的指針、一個(gè)是該緩沖中有效的字符記數(shù)以及一個(gè)緩沖區(qū)長(zhǎng)度。 有效字符數(shù)的大小可以是從0到該緩沖最大長(zhǎng)度值減1之間的任何數(shù)（因?yàn)樽址Y(jié)尾有一個(gè)NULL字符）。字符記數(shù)和緩沖區(qū)長(zhǎng)度被巧妙隱藏。
除非你做一些特殊的操作，否則你不可能知道給CString對(duì)象分配的緩沖區(qū)的長(zhǎng)度。這樣，即使你獲得了該0緩沖的地址，你也無(wú)法更改其中的內(nèi)容，不能截短字符串，也 絕對(duì)沒有辦法加長(zhǎng)它的內(nèi)容，否則第一時(shí)間就會(huì)看到溢出。
LPCTSTR 操作符（或者更明確地說(shuō)就是 TCHAR * 操作符）在 CString 類中被重載了，該操作符的定義是返回緩沖區(qū)的地址，因此，如果你需要一個(gè)指向 CString 的 字符串指針的話，可以這樣做：
?
CString s("GrayCat"); LPCTSTR p = s;它可以正確地運(yùn)行。這是由C語(yǔ)言的強(qiáng)制類型轉(zhuǎn)化規(guī)則實(shí)現(xiàn)的。當(dāng)需要強(qiáng)制類型轉(zhuǎn)化時(shí)，C++規(guī)測(cè)容許這種選擇。比如，你可以將（浮點(diǎn)數(shù)）定義為將某個(gè)復(fù)數(shù) （有一對(duì)浮點(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è)你買來(lái)的DLL中）：
你象下面這樣調(diào)用它：
CString file("c://myfiles//coolstuff") BOOL result = DoSomethingCool(file); 它能正確運(yùn)行。因?yàn)?DoSomethingCool 函數(shù)已經(jīng)說(shuō)明了需要一個(gè) LPCTSTR 類型的參數(shù)，因此 LPCTSTR 被應(yīng)用于該參數(shù)，在 MFC 中就是返回的串地址。
如果你要格式化字符串怎么辦呢？
注意由于在可變參數(shù)列表中的值（在函數(shù)說(shuō)明中是以“...”表示的）并沒有隱含一個(gè)強(qiáng)制類型轉(zhuǎn)換操作符。你會(huì)得到什么結(jié)果呢？
一個(gè)令人驚訝的結(jié)果，我們得到的實(shí)際結(jié)果串是：
因?yàn)?MFC 的設(shè)計(jì)者們?cè)谠O(shè)計(jì) CString 數(shù)據(jù)類型時(shí)非常小心， CString 類型表達(dá)式求值后指向了字符串，所以這里看不到任何象 Format 或 sprintf 中的強(qiáng)制類型轉(zhuǎn)換，你仍然可以得到正確的行為。描述 CString 的附加數(shù)據(jù)實(shí)際上在 CString 名義地址之后。
有一件事情你是不能做的，那就是修改字符串。比如，你可能會(huì)嘗試用“,”代替“.”（不要做這樣的，如果你在乎國(guó)際化問題，你應(yīng)該使用十進(jìn)制轉(zhuǎn)換的 National Language Support 特性，），下面是個(gè)簡(jiǎn)單的例子：
這時(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ì)反映所做的修改。此外，如果字符串長(zhǎng)度恰好是該字符串物理限制的長(zhǎng)度（梢后還會(huì)講到這個(gè)問題），那么擴(kuò)展該字符串將改寫緩沖以外的任何數(shù)據(jù)，那是你無(wú)權(quán)進(jìn)行寫操作的內(nèi)存（不對(duì)嗎？），你會(huì)毀換壞不屬于你的內(nèi)存。這是應(yīng)用程序真正的死亡處方。
CString轉(zhuǎn)化成char* 之二：使用 CString 對(duì)象的 GetBuffer 方法；
如果你需要修改 CString 中的內(nèi)容，它有一個(gè)特殊的方法可以使用，那就是 GetBuffer，它的作用是返回一個(gè)可寫的緩沖指針。 如果你只是打算修改字符或者截短字符串，你完全可以這樣做：
這是 GetBuffer 的第一種用法，也是最簡(jiǎn)單的一種，不用給它傳遞參數(shù)，它使用默認(rèn)值 0，意思是：“給我這個(gè)字符串的指針，我保證不加長(zhǎng)它”。當(dāng)你調(diào)用 ReleaseBuffer 時(shí)，字符串的實(shí)際長(zhǎng)度會(huì)被重新計(jì)算，然后存入 CString 對(duì)象中。
必須強(qiáng)調(diào)一點(diǎn)，在 GetBuffer 和 ReleaseBuffer 之間這個(gè)范圍，一定不能使用你要操作的這個(gè)緩沖的 CString 對(duì)象的任何方法。因?yàn)?ReleaseBuffer 被調(diào)用之前，該 CString 對(duì)象的完整性得不到保障。研究以下代碼：
假設(shè)你想增加字符串的長(zhǎng)度，你首先要知道這個(gè)字符串可能會(huì)有多長(zhǎng)，好比是聲明字符串?dāng)?shù)組的時(shí)候用：
char buffer[1024];表示 1024 個(gè)字符空間足以讓你做任何想做得事情。在 CString 中與之意義相等的表示法：
LPTSTR p = s.GetBuffer(1024); 調(diào)用這個(gè)函數(shù)后，你不僅獲得了字符串緩沖區(qū)的指針，而且同時(shí)還獲得了長(zhǎng)度至少為 1024 個(gè)字符的空間（注意，我說(shuō)的是“字符”，而不是“字節(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è)固定長(zhǎng)度的緩沖，對(duì)它進(jìn)行 sprintf 操作，然后將它賦值給一個(gè) CString：
雖然更好的形式可以這么做：
CString s; s.Format(_T("%...."), args, ...);如果你的字符串長(zhǎng)度萬(wàn)一超過 256 個(gè)字符的時(shí)候，不會(huì)破壞堆棧。
另外一個(gè)常見的錯(cuò)誤是：既然固定大小的內(nèi)存不工作，那么就采用動(dòng)態(tài)分配字節(jié)，這種做法弊端更大：
它可以能被簡(jiǎn)單地寫成：
CString s;s.Format(_T("%s is equal to %s, valid data"), parm1, parm2); 需要注意 sprintf 例子都不是 Unicode 就緒的，盡管你可以使用 tsprintf 以及用 _T() 來(lái)包圍格式化字符串，但是基本 思路仍然是在走彎路，這這樣很容易出錯(cuò)。
CString to char * 之三：和控件的接口；
我們經(jīng)常需要把一個(gè) CString 的值傳遞給一個(gè)控件，比如，CTreeCtrl。MFC為我們提供了很多便利來(lái)重載這個(gè)操作，但是 在大多數(shù)情況下，你使用“原始”形式的更新，因此需要將墨某個(gè)串指針存儲(chǔ)到 TVINSERTITEMSTRUCT 結(jié)構(gòu)的 TVITEM 成員中。如下：
為什么編譯器會(huì)報(bào)錯(cuò)呢？明明看起來(lái)很完美的用法啊！但是事實(shí)上如果你看看 TVITEM 結(jié)構(gòu)的定義你就會(huì)明白，在 TVITEM 結(jié)構(gòu)中 pszText?成員的聲明如下：
LPTSTR pszText; int cchTextMax;因此，賦值不是賦給一個(gè) LPCTSTR 類型的變量，而且編譯器無(wú)法知道如何將賦值語(yǔ)句右邊強(qiáng)制轉(zhuǎn)換成 LPCTSTR。好吧，你說(shuō)，那我就改成這樣：
tvi.item.pszText = (LPCTSTR)s; //編譯器依然會(huì)報(bào)錯(cuò)。編譯器之所以依然報(bào)錯(cuò)是因?yàn)槟阍噲D把一個(gè) LPCTSTR 類型的變量賦值給一個(gè) LPTSTR 類型的變量，這種操作在C或C++中是被禁止的。你不能用這種方法 來(lái)濫用常量指針與非常量指針概念，否則，會(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)無(wú)法區(qū)分它是用來(lái)讀還是用來(lái)寫。
因此，你會(huì)常常在我的代碼中看到如下的用法：
它把 CString 強(qiáng)制類型轉(zhuǎn)化成 LPCTSTR，也就是說(shuō)先獲得改字符串的地址，然后再?gòu)?qiáng)制類型轉(zhuǎn)化成 LPTSTR，以便可以對(duì)之進(jìn)行賦值操作。 注意這只有在使用 Set 或 Insert 之類的方法才有效！如果你試圖獲取數(shù)據(jù)，則不能這么做。
如果你打算獲取存儲(chǔ)在控件中的數(shù)據(jù)，則方法稍有不同，例如，對(duì)某個(gè) CTreeCtrl 使用 GetItem 方法，我想獲取項(xiàng)目的文本。我知道這些 文本的長(zhǎng)度不會(huì)超過 MY_LIMIT，因此我可以這樣寫：
可以看出來(lái)，其實(shí)上面的代碼對(duì)所有類型的 Set 方法都適用，但是并不需要這么做，因?yàn)樗械念?Set 方法（包括 Insert方法）不會(huì)改變字符串的內(nèi)容。但是當(dāng)你需要寫 CString 對(duì)象時(shí)，必須保證緩沖是可寫的，這正是 GetBuffer 所做的事情。再次強(qiáng)調(diào)： 一旦做了一次 GetBuffer 調(diào)用，那么在調(diào)用 ReleaseBuffer 之前不要對(duì)這個(gè) CString 對(duì)象做任何操作。
5、CString 型轉(zhuǎn)化成 BSTR 型
當(dāng)我們使用 ActiveX 控件編程時(shí)，經(jīng)常需要用到將某個(gè)值表示成 BSTR 類型。BSTR 是一種記數(shù)字符串，Intel平臺(tái)上的寬字符串（Unicode），并且 可以包含嵌入的 NULL 字符。
你可以調(diào)用 CString 對(duì)象的 AllocSysString 方法將 CString 轉(zhuǎn)化成 BSTR：
現(xiàn)在指針 b 指向的就是一個(gè)新分配的 BSTR 對(duì)象，該對(duì)象是 CString 的一個(gè)拷貝，包含終結(jié) NULL字符。現(xiàn)在你可以將它傳遞給任何需要 BSTR 的接口。通常，BSTR 由接收它的組件來(lái)釋放，如果你需要自己釋放 BSTR 的話，可以這么做：
::SysFreeString(b); 對(duì)于如何表示傳遞給 ActiveX 控件的字符串，在微軟內(nèi)部曾一度爭(zhēng)論不休，最后 Visual Basic 的人占了上風(fēng)，BSTR（“Basic String”的首字母縮寫）就是這場(chǎng)爭(zhēng)論的結(jié)果。
6、BSTR 型轉(zhuǎn)化成 CString 型
由于 BSTR 是記數(shù) Unicode 字符串，你可以用標(biāo)準(zhǔn)轉(zhuǎn)換方法來(lái)創(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程序中：
對(duì)于單個(gè)的 BSTR 串來(lái)說(shuō)，這種用法可以工作得很好，這是因?yàn)?CString 有一個(gè)特殊的構(gòu)造函數(shù)以LPCWSTR（BSTR正是這種類型） 為參數(shù)，并將它轉(zhuǎn)化成 ANSI 類型。專門檢查是必須的，因?yàn)?BSTR 可能為空值，而 CString 的構(gòu)造函數(shù)對(duì)于 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，那么它別無(wú)選擇，只能和 LPCWSTR 參數(shù)匹配。
在 Unicode 模式下，它的構(gòu)造函數(shù)是：
正如上面所表示的，在 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 字符。 也就是說(shuō)，如果串中含有嵌入的 NUL字節(jié)，CString 將會(huì)計(jì)算出錯(cuò)誤的串長(zhǎng)度。你必須自己處理它。如果你看看 strcore.cpp 中的構(gòu)造函數(shù)，你會(huì)發(fā)現(xiàn) 它們都調(diào)用了lstrlen，也就是計(jì)算字符串的長(zhǎng)度。
注意從 Unicode 到 ANSI 的轉(zhuǎn)換使用帶專門參數(shù)的 ::WideCharToMultiByte，如果你不想使用這種默認(rèn)的轉(zhuǎn)換方式，則必須編寫自己的轉(zhuǎn)化代碼。
如果你在 UNICODE 模式下編譯代碼，你可以簡(jiǎn)單地寫成：
如果是 ANSI 模式，則需要更復(fù)雜的過程來(lái)轉(zhuǎn)換。注意這個(gè)代碼使用與 ::WideCharToMultiByte 相同的參數(shù)值。所以你 只能在想要改變這些參數(shù)進(jìn)行轉(zhuǎn)換時(shí)使用該技術(shù)。例如，指定不同的默認(rèn)字符，不同的標(biāo)志集等。
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); // don''t care if default useds.ReleaseBuffer(); #endifreturn s; } 我并不擔(dān)心如果 BSTR 包含沒有映射到 8 位字符集的 Unicode 字符時(shí)會(huì)發(fā)生什么，因?yàn)槲抑付?:WideCharToMultiByte 的最后兩個(gè)參數(shù)為 NULL。這就是你可能需要改變的地方。
7、VARIANT 型轉(zhuǎn)化成 CString 型
事實(shí)上，我從來(lái)沒有這么做過，因?yàn)槲覜]有用 COM/OLE/ActiveX 編寫過程序。但是我在microsoft.public.vc.mfc 新聞組上看到了 Robert Quirk 的一篇帖子談到了這種轉(zhuǎn)化，我覺得把他的文章包含在我的文章里是不太好的做法，所以在這里多做一些解釋和演示。如果和他的文章有相孛的地方可能是我的疏忽。
VARIANT 類型經(jīng)常用來(lái)給 COM 對(duì)象傳遞參數(shù)，或者接收從 COM 對(duì)象返回的值。你也能自己編寫返回 VARIANT 類型的方法，函數(shù)返回什么類型 依賴可能（并且常常）方法的輸入?yún)?shù)（比如，在自動(dòng)化操作中，依賴與你調(diào)用哪個(gè)方法。IDispatch::Invoke 可能返回（通過其一個(gè)參數(shù)）一個(gè) 包含有BYTE、WORD、float、double、date、BSTR 等等 VARIANT 類型的結(jié)果，（詳見 MSDN 上的 VARIANT 結(jié)構(gòu)的定義）。在下面的例子中，假設(shè) 類型是一個(gè)BSTR的變體，也就是說(shuō)在串中的值是通過 bsrtVal 來(lái)引用，其優(yōu)點(diǎn)是在 ANSI 應(yīng)用中，有一個(gè)構(gòu)造函數(shù)會(huì)把 LPCWCHAR 引用的值轉(zhuǎn)換為一個(gè) CString（見 BSTR-to-CString 部分）。在 Unicode 模式中，將成為標(biāo)準(zhǔn)的 CString 構(gòu)造函數(shù)，參見對(duì)缺省::WideCharToMultiByte 轉(zhuǎn)換的告誡，以及你覺得是否可以接受（大多數(shù)情況下，你會(huì)滿意的）。
你還可以根據(jù) vt 域的不同來(lái)建立更通用的轉(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 */ } 8、載入字符串表資源
如果你想創(chuàng)建一個(gè)容易進(jìn)行語(yǔ)言版本移植的應(yīng)用程序，你就不能在你的源代碼中直接包含本土語(yǔ)言字符串 （下面這些例子我用的語(yǔ)言都是英語(yǔ)，因?yàn)槲业谋就琳Z(yǔ)是英語(yǔ)），比如下面這種寫法就很糟：
你應(yīng)該把你所有特定語(yǔ)言的字符串單獨(dú)擺放（調(diào)試信息、在發(fā)布版本中不出現(xiàn)的信息除外）。這意味著向下面這樣寫比較好：
s.Format(_T("%d - %s"), code, text);在你的程序中，文字字符串不是語(yǔ)言敏感的。不管怎樣，你必須很小心，不要使用下面這樣的串：
// fmt is "Error in %s file %s" // readorwrite is "reading" or "writing" s.Format(fmt, readorwrite, filename);這是我的切身體會(huì)。在我的第一個(gè)國(guó)際化的應(yīng)用程序中我犯了這個(gè)錯(cuò)誤，盡管我懂德語(yǔ)，知道在德語(yǔ)的語(yǔ)法中動(dòng)詞放在句子的最后面，我們的德國(guó)方面的發(fā)行人還是苦苦的抱怨他們不得不提取那些不可思議的德語(yǔ)錯(cuò)誤提示信息然后重新格式化以讓它們能正常工作。比較好的辦法（也是我現(xiàn)在使用的辦法）是使用兩個(gè)字符串，一個(gè)用 于讀，一個(gè)用于寫，在使用時(shí)加載合適的版本，使得它們對(duì)字符串參數(shù)是非敏感的。也就是說(shuō)加載整個(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)問題，比如在英語(yǔ)中，可以是主語(yǔ)-賓語(yǔ)，主語(yǔ)-謂語(yǔ)，動(dòng)詞-賓語(yǔ)的結(jié)構(gòu)等等。
在這里，我們并不討論 FormatMessage，其實(shí)它比 sprintf/Format 還要有優(yōu)勢(shì)，但是不太容易和CString 結(jié)合使用。解決這種問題的辦法就是我們按照參數(shù)出現(xiàn)在參數(shù)表中的位置給參數(shù)取名字，這樣在你輸出的時(shí)候就不會(huì)把他們的位置排錯(cuò)了。
接下來(lái)我們討論我們這些獨(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 文件中：
注意：這些資源都以 Unicode 的格式保存，不管你是在什么環(huán)境下編譯。他們?cè)赪in9x系統(tǒng)上也是以Unicode 的形式存在，雖然 Win9x 不能真正處理 Unicode。
然后你可以這樣使用這些資源：
// 在使用資源串表之前，程序是這樣寫的：
// 使用資源串表之后，程序這樣寫：
CString fmt;if(...)fmt.LoadString(IDS_READING_FILE);elsefmt.LoadString(DS_WRITING_FILE);...// much laterCString s;s.Format(fmt, filename);現(xiàn)在，你的代碼可以移植到任何語(yǔ)言中去。LoadString 方法需要一個(gè)字符串資源的 ID 作為參數(shù)，然后它從 STRINGTABLE 中取出它對(duì)應(yīng)的字符串，賦值給 CString 對(duì)象。 CString 對(duì)象的構(gòu)造函數(shù)還有一個(gè)更加聰明的特征可以簡(jiǎn)化 STRINGTABLE 的使用。這個(gè)用法在 CString::CString 的文檔中沒有指出，但是在 構(gòu)造函數(shù)的示例程序中使用了。（為什么這個(gè)特性沒有成為正式文檔的一部分，而是放在了一個(gè)例子中，我記不得了！）——【譯者注：從這句話看，作者可能是CString的設(shè)計(jì)者。其實(shí)前面還有一句類似的話。說(shuō)他沒有對(duì)使用GetBuffer(0)獲得的指針指向的地址是否可讀做有效性檢查 】。這個(gè)特征就是：如果你將一個(gè)字符串資源的ID強(qiáng)制類型轉(zhuǎn)換為 LPCTSTR，將會(huì)隱含調(diào)用 LoadString。因此，下面兩個(gè)構(gòu)造字符串的例子具有相同的效果，而且其 ASSERT 在debug模式下不會(huì)被觸發(fā)：
CString s; s.LoadString(IDS_WHATEVER); CString t( (LPCTSTR)IDS_WHATEVER ); ASSERT(s == t);//不會(huì)被觸發(fā)，說(shuō)明s和t是相同的。 現(xiàn)在，你可能會(huì)想：這怎么可能工作呢？我們?cè)趺茨馨?STRINGTABLE ID 轉(zhuǎn)化成一個(gè)指針呢？很簡(jiǎn)單：所有的字符串 ID 都在1~65535這個(gè)范圍內(nèi)，也就是說(shuō)，它所有的高位都是0，而我們?cè)诔绦蛑兴褂玫闹羔樖遣豢赡苄∮?5535的，因?yàn)槌绦虻牡?64K 內(nèi)存永遠(yuǎn)也不可能存在的，如果你試圖訪問0x00000000到0x0000FFFF之間的內(nèi)存，將會(huì)引發(fā)一個(gè)內(nèi)存越界錯(cuò)誤。所以說(shuō)1~65535的值不可能是一個(gè)內(nèi)存地址，所以我們可以用這些值來(lái)作為字符串資源的ID。
我傾向于使用 MAKEINTRESOURCE 宏顯式地做這種轉(zhuǎn)換。我認(rèn)為這樣可以讓代碼更加易于閱讀。這是個(gè)只適合在 MFC 中使用的標(biāo)準(zhǔn)宏。你要記住，大多數(shù)的方法即可以接受一個(gè) UINT 型的參數(shù)，也可以接受一個(gè) LPCTSTR 型的參數(shù)，這是依賴 C++ 的重載功能做到的。C++重載函數(shù)帶來(lái)的 弊端就是造成所有的強(qiáng)制類型轉(zhuǎn)化都需要顯示聲明。同樣，你也可以給很多種結(jié)構(gòu)只傳遞一個(gè)資源名。
告訴你吧：我不僅只是在這里鼓吹，事實(shí)上我也是這么做的。在我的代碼中，你幾乎不可能找到一個(gè)字符串，當(dāng)然，那些只是偶然在調(diào)試中出現(xiàn)的或者和語(yǔ)言無(wú)關(guān)的字符串除外。
9、CString 和臨時(shí)對(duì)象
這是出現(xiàn)在 microsoft.public.vc.mfc 新聞組中的一個(gè)小問題，我簡(jiǎn)單的提一下，這個(gè)問題是有個(gè)程序員需要往注冊(cè)表中寫入一個(gè)字符串，他寫道：
我試著用 RegSetValueEx() 設(shè)置一個(gè)注冊(cè)表鍵的值，但是它的結(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í)，它就變成垃圾了。以下是我的程序段：
這個(gè) Name 字符串的長(zhǎng)度小于 20，所以我不認(rèn)為是 GetBuffer 的參數(shù)的問題。
真讓人困惑，請(qǐng)幫幫我。
親愛的 Frustrated，
你犯了一個(gè)相當(dāng)微妙的錯(cuò)誤，聰明反被聰明誤，正確的代碼應(yīng)該象下面這樣：
為什么我寫的代碼能行而你寫的就有問題呢？主要是因?yàn)楫?dāng)你調(diào)用 GetName 時(shí)返回的 CString 對(duì)象是一個(gè)臨時(shí)對(duì)象。參見：《C++ Reference manual》§12.2
在一些環(huán)境中，編譯器有必要?jiǎng)?chuàng)建一個(gè)臨時(shí)對(duì)象，這樣引入臨時(shí)對(duì)象是依賴于實(shí)現(xiàn)的。如果編譯器引入的這個(gè)臨時(shí)對(duì)象所屬的類有構(gòu)造函數(shù)的話，編譯器要確保這個(gè)類的構(gòu)造函數(shù)被調(diào)用。同樣的，如果這個(gè)類聲明有析構(gòu)函數(shù)的話，也要保證這個(gè)臨時(shí)對(duì)象的析構(gòu)函數(shù)被調(diào)用。
編譯器必須保證這個(gè)臨時(shí)對(duì)象被銷毀了。被銷毀的確切地點(diǎn)依賴于實(shí)現(xiàn).....這個(gè)析構(gòu)函數(shù)必須在退出創(chuàng)建該臨時(shí)對(duì)象的范圍之前被調(diào)用。
大部分的編譯器是這樣設(shè)計(jì)的：在臨時(shí)對(duì)象被創(chuàng)建的代碼的下一個(gè)執(zhí)行步驟處隱含調(diào)用這個(gè)臨時(shí)對(duì)象的析構(gòu)函數(shù)，實(shí)現(xiàn)起來(lái)，一般都是在下一個(gè)分號(hào)處。因此，這個(gè) CString 對(duì)象在 GetBuffer 調(diào)用之后就被析構(gòu)了（順便提一句，你沒有理由給 GetBuffer 函數(shù)傳遞一個(gè)參數(shù)，而且沒有使用ReleaseBuffer 也是不對(duì)的）。所以 GetBuffer 本來(lái)返回的是指向這個(gè)臨時(shí)對(duì)象中字符串的地址的指針，但是當(dāng)這個(gè)臨時(shí)對(duì)象被析構(gòu)后，這塊內(nèi)存就被釋放了。然后 MFC 的調(diào)試內(nèi)存分配器會(huì)重新為這塊內(nèi)存全部填上 0xDD，顯示出來(lái)剛好就是“Ý”符號(hào)。在這個(gè)時(shí)候你向注冊(cè)表中寫數(shù)據(jù)，字符串的內(nèi)容當(dāng)然全被破壞了。
我們不應(yīng)該立即把這個(gè)臨時(shí)對(duì)象轉(zhuǎn)化成 char* 類型，應(yīng)該先把它保存到一個(gè) CString 對(duì)象中，這意味著把臨時(shí)對(duì)象復(fù)制了一份，所以當(dāng)臨時(shí)的 CString 對(duì)象被析構(gòu)了之后，這個(gè) CString 對(duì)象中的值依然保存著。這個(gè)時(shí)候再向注冊(cè)表中寫數(shù)據(jù)就沒有問題了。
此外，我的代碼是具有 Unicode 意識(shí)的。那個(gè)操作注冊(cè)表的函數(shù)需要一個(gè)字節(jié)大小，使用lstrlen(Name+1) 得到的實(shí)際結(jié)果對(duì)于 Unicode 字符來(lái)說(shuō)比 ANSI 字符要小一半，而且它也不能從這個(gè)字符串的第二個(gè)字符起開始計(jì)算，也許你的本意是 lstrlen(Name) + 1（OK，我承認(rèn)，我也犯了同樣的錯(cuò)誤！）。不論如何，在 Unicode 模式下，所有的字符都是2個(gè)字節(jié)大小，我們需要處理這個(gè)問題。微軟的文檔令人驚訝地對(duì)此保持緘默：REG_SZ 的值究竟是以字節(jié)計(jì)算還是以字符計(jì)算呢？我們假設(shè)它指的是以字節(jié)為單位計(jì)算，你需要對(duì)你的代碼做一些修改來(lái)計(jì)算這個(gè)字符串所含有的字節(jié)大小。
10、CString 的效率
CString 的一個(gè)問題是它確實(shí)掩藏了一些低效率的東西。從另外一個(gè)方面講，它也確實(shí)可以被實(shí)現(xiàn)得更加高效，你可能會(huì)說(shuō)下面的代碼：
比起下面的代碼來(lái)，效率要低多了：
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è)字符串連接起來(lái)效率多低啊。事實(shí)上，在很多情況下根本就不需要復(fù)制源字符串（在 += 操作符左邊的字符串）。
在 VC++6.0 中，Release 模式下，所有的 CString 中的緩存都是按預(yù)定義量子分配的。所謂量子，即確定為 64、128、256 或者 512 字節(jié)。這意味著除非字符串非常長(zhǎng)，連接字符串的操作實(shí)際上就是 strcat 經(jīng)過優(yōu)化后的版本（因?yàn)樗辣镜氐淖址畱?yīng)該在什么地方結(jié)束，所以不需要尋找字符串的結(jié)尾；只需要把內(nèi)存中的數(shù)據(jù)拷貝到指定的地方即可）加上重新計(jì)算字符串的長(zhǎng)度。所以它的執(zhí)行效率和純 C 的代碼是一樣的，但是它更容易寫、更容易維護(hù)和更容易理解。
如果你還是不能確定究竟發(fā)生了怎樣的過程，請(qǐng)看看 CString 的源代碼，strcore.cpp，在你 vc98的安裝目錄的 mfc/src 子目錄中。看看 ConcatInPlace 方法，它被在所有的 += 操作符中調(diào)用。
啊哈！難道 CString 真的這么"高效"嗎？比如，如果我創(chuàng)建
然后我并不是得到了一個(gè)高效的、精簡(jiǎn)的5個(gè)字節(jié)大小的緩沖區(qū)（4個(gè)字符加一個(gè)結(jié)束字符），系統(tǒng)將給我分配64個(gè)字節(jié)，而其中59個(gè)字節(jié)都被浪費(fèi)了。
如果你也是這么想的話，那么就請(qǐng)準(zhǔn)備好接受再教育吧。可能在某個(gè)地方某個(gè)人給你講過盡量使用少的空間是件好事情。不錯(cuò)，這種說(shuō)法的確正確，但是他忽略了事實(shí)中一個(gè)很重要的方面。
如果你編寫的是運(yùn)行在16K EPROMs下的嵌入式程序的話，你有理由盡量少使用空間，在這種環(huán)境下，它能使你的程序更健壯。但是在 500MHz, 256MB的機(jī)器上寫 Windows 程序，如果你還是這么做，它只會(huì)比你認(rèn)為的“低效”的代碼運(yùn)行得更糟。
舉例來(lái)說(shuō)。字符串的大小被認(rèn)為是影響效率的首要因素，使字符串盡可能小可以提高效率，反之則降低效率，這是大家一貫的想法。但是這種想法是不對(duì)的，精確的內(nèi)存分配的后果要在程序運(yùn)行了好幾個(gè)小時(shí)后才能體現(xiàn)得出來(lái)，那時(shí)，程序的堆中將充滿小片的內(nèi)存，它們太小以至于不能用來(lái)做任何事，但是他們?cè)黾恿四愠绦虻膬?nèi)存用量，增加了內(nèi)存頁(yè)面交換的次數(shù)，當(dāng)頁(yè)面交換的次數(shù)增加到系統(tǒng)能夠忍受的上限，系統(tǒng)則會(huì)為你的程序分配更多的頁(yè)面，直到你的程序占用了所有的可用內(nèi)存。由此可見，雖然內(nèi)存碎片是決定效率的次要因素，但正是這些因素實(shí)際控制了系統(tǒng)的行為，最終，它損害了系統(tǒng)的可靠性，這是令人無(wú)法接受的。
記住，在 debug 模式下，內(nèi)存往往是精確分配的，這是為了更好的排錯(cuò)。
假設(shè)你的應(yīng)用程序通常需要連續(xù)工作好幾個(gè)月。比如，我常打開 VC++，Word，PowerPoint，Frontpage，Outlook Express，Forté Agent，Internet Explorer和其它的一些程序，而且通常不關(guān)閉它們。我曾經(jīng)夜以繼日地連續(xù)用 PowerPoint 工作了好幾天（反之，如果你不幸不得不使用像 Adobe FrameMaker 這樣的程序的話，你將會(huì)體會(huì)到可靠性的重要；這個(gè)程序機(jī)會(huì)每天都要崩潰4~6次，每次都是因?yàn)橛猛炅怂械目臻g并填滿我所有的交換頁(yè)面）。所以精確內(nèi)存分配是不可取的，它會(huì)危及到系統(tǒng)的可靠性，并引起應(yīng)用程序崩潰。
按量子的倍數(shù)為字符串分配內(nèi)存，內(nèi)存分配器就可以回收用過的內(nèi)存塊，通常這些回收的內(nèi)存塊馬上就可以被其它的 CString 對(duì)象重新用到，這樣就可以保證碎片最少。分配器的功能加強(qiáng)了，應(yīng)用程序用到的內(nèi)存就能盡可能保持最小，這樣的程序就可以運(yùn)行幾個(gè)星期或幾個(gè)月而不出現(xiàn)問題。
題外話：很多年以前，我們?cè)?CMU 寫一個(gè)交互式系統(tǒng)的時(shí)候，一些對(duì)內(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)為：與其讓指令做長(zhǎng)時(shí)間的存取內(nèi)存操作，還不如簡(jiǎn)單的忽略那些太小的內(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.）他是對(duì)的。
永遠(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)算符只是一種特例，如果你寫成下面這樣：
則每一個(gè) + 的應(yīng)用會(huì)造成一個(gè)新的字符串被創(chuàng)建和一次復(fù)制操作。
總結(jié)
以上是使用 CString 的一些技巧。我每天寫程序的時(shí)候都會(huì)用到這些。CString 并不是一種很難使用的類，但是 MFC 沒有很明顯的指出這些特征，需要你自己去探索、去發(fā)現(xiàn)。
總結(jié)
以上是生活随笔為你收集整理的CString 操作指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 小米平板 6 / Pro 核心配置曝光：
- 下一篇： SSD、内存价格狂降不止：三星、SK海力