VC++中的CString操作指南 通過閱讀本文你可以學(xué)習(xí)如何有效地使用 CString翻诉。 　　CString 是一種很有用的數(shù)據(jù)類型滩援。它們很大程度上簡化了MFC中的許多操作摔蓝，使得MFC在做字符串操作的時(shí)候方便了很多。不管怎樣帆离，使用CString有很多特殊的技巧，特別是對于純C背景下走出來的程序員來說有點(diǎn)難以學(xué)習(xí)结澄。這篇文章就來討論這些技巧哥谷。 　　使用CString可以讓你對字符串的操作更加直截了當(dāng)。這篇文章不是CString的完全手冊麻献，但囊括了大部分常見基本問題们妥。 這篇文章包括以下內(nèi)容： CString 對象的連接 格式化字符串（包括 int 型轉(zhuǎn)化為 CString ） CString 型轉(zhuǎn)化成 int 型 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* 之三: 和控件的接口 CString 型轉(zhuǎn)化成 BSTR 型； BSTR 型轉(zhuǎn)化成 CString 型勉吻； VARIANT 型轉(zhuǎn)化成 CString 型监婶； 載入字符串表資源； CString 和臨時(shí)對象齿桃； CString 的效率惑惶； 總結(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的意識藐唠，當(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]) ) 　　這個(gè)宏不僅可以用來解決Unicode的字符串長度的問題倒堕，也可以用在編譯時(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í)長度鲜结，你可能會(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意識的程序而已。如果你在默認(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ù)是無符號的（unsigned），而后者相反担租≡颐瘢看下面的例子： 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)獒槍?CString 和 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 意識的代碼總是一件好事，比如： 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 意識： 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)識上還存在許多混亂冒签，正確的使用方法有很多在抛，但錯(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平臺上的寬字符串（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; } 　　如果是 ANSI 模式把曼，則需要更復(fù)雜的過程來轉(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 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; } 　　我并不擔(dān)心如果 BSTR 包含沒有映射到 8 位字符集的 Unicode 字符時(shí)會(huì)發(fā)生什么，因?yàn)槲抑付?:WideCharToMultiByte 的最后兩個(gè)參數(shù)為 NULL僚饭。這就是你可能需要改變的地方震叮。 7、VARIANT 型轉(zhuǎn)化成 CString 型 　　事實(shí)上鳍鸵，我從來沒有這么做過苇瓣，因?yàn)槲覜]有用 COM/OLE/ActiveX 編寫過程序。但是我在microsoft.public.vc.mfc 新聞組上看到了 Robert Quirk 的一篇帖子談到了這種轉(zhuǎn)化偿乖，我覺得把他的文章包含在我的文章里是不太好的做法钓简，所以在這里多做一些解釋和演示。如果和他的文章有相孛的地方可能是我的疏 忽汹想。 　　VARIANT 類型經(jīng)常用來給 COM 對象傳遞參數(shù)，或者接收從 COM 對象返回的值撤蚊。你也能自己編寫返回 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的變體私恬，也就是說在串中的值是通過 bsrtVal 來引用债沮，其優(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ù)，參見對缺省::WideCharToMultiByte 轉(zhuǎn)換的告誡荣德，以及你覺得是否可以接受（大多數(shù)情況下闷煤，你會(huì)滿意的）。 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 */ } 8鲤拿、載入字符串表資源 　　如果你想創(chuàng)建一個(gè)容易進(jìn)行語言版本移植的應(yīng)用程序，你就不能在你的源代碼中直接包含本土語言字符串 （下面這些例子我用的語言都是英語饲宛，因?yàn)槲业谋就琳Z是英語）皆愉，比如下面這種寫法就很糟： 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); 　　現(xiàn)在裹粤，你的代碼可以移植到任何語言中去。LoadString 方法需要一個(gè)字符串資源的 ID 作為參數(shù)蜂林，然后它從 STRINGTABLE 中取出它對應(yīng)的字符串遥诉，賦值給 CString 對象。 CString 對象的構(gòu)造函數(shù)還有一個(gè)更加聰明的特征可以簡化 STRINGTABLE 的使用噪叙。這個(gè)用法在 CString::CString 的文檔中沒有指出矮锈，但是在 構(gòu)造函數(shù)的示例程序中使用了。（為什么這個(gè)特性沒有成為正式文檔的一部分睁蕾，而是放在了一個(gè)例子中苞笨，我記不得了！）——【譯者注：從這句話看惫霸，作者可能是 CString的設(shè)計(jì)者。其實(shí)前面還有一句類似的話葱弟。說他沒有對使用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ā)，說明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í)候纱皆，總是得到一些垃 圾："YYYY...YYYYYY" 為了確認(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)); 　　為什么我寫的代碼能行而你寫的就有問題呢？主要是因?yàn)楫?dāng)你調(diào)用 GetName 時(shí)返回的 CString 對象是一個(gè)臨時(shí)對象面氓。參見：《C++ Reference manual》§12.2 　　在一些環(huán)境中兵钮，編譯器有必要?jiǎng)?chuàng)建一個(gè)臨時(shí)對象，這樣引入臨時(shí)對象是依賴于實(shí)現(xiàn)的舌界。如果編譯器引入的這個(gè)臨時(shí)對象所屬的類有構(gòu)造函數(shù)的話掘譬，編譯器要確保這個(gè)類的構(gòu)造函數(shù)被調(diào)用。同樣的呻拌，如果這個(gè)類聲明有析構(gòu)函數(shù)的話葱轩，也要保證這個(gè)臨時(shí)對象的析構(gòu)函數(shù)被調(diào)用。 　　編譯器必須保證這個(gè)臨時(shí)對象被銷毀了藐握。被銷毀的確切地點(diǎn)依賴于實(shí)現(xiàn).....這個(gè)析構(gòu)函數(shù)必須在退出創(chuàng)建該臨時(shí)對象的范圍之前被調(diào)用靴拱。 　 　大部分的編譯器是這樣設(shè)計(jì)的：在臨時(shí)對象被創(chuàng)建的代碼的下一個(gè)執(zhí)行步驟處隱含調(diào)用這個(gè)臨時(shí)對象的析構(gòu)函數(shù)，實(shí)現(xiàn)起來猾普，一般都是在下一個(gè)分號處袜炕。因此，這 個(gè) CString 對象在 GetBuffer 調(diào)用之后就被析構(gòu)了（順便提一句初家，你沒有理由給 GetBuffer 函數(shù)傳遞一個(gè)參數(shù)偎窘，而且沒有使用ReleaseBuffer 也是不對的）。所以 GetBuffer 本來返回的是指向這個(gè)臨時(shí)對象中字符串的地址的指針溜在，但是當(dāng)這個(gè)臨時(shí)對象被析構(gòu)后陌知，這塊內(nèi)存就被釋放了。然后 MFC 的調(diào)試內(nèi)存分配器會(huì)重新為這塊內(nèi)存全部填上 0xDD掖肋，顯示出來剛好就是“Y”符號仆葡。在這個(gè)時(shí)候你向注冊表中寫數(shù)據(jù)，字符串的內(nèi)容當(dāng)然全被破壞了培遵。 　　我們不應(yīng)該立即 把這個(gè)臨時(shí)對象轉(zhuǎn)化成 char* 類型浙芙，應(yīng)該先把它保存到一個(gè) CString 對象中，這意味著把臨時(shí)對象復(fù)制了一份籽腕，所以當(dāng)臨時(shí)的 CString 對象被析構(gòu)了之后嗡呼，這個(gè) CString 對象中的值依然保存著。這個(gè)時(shí)候再向注冊表中寫數(shù)據(jù)就沒有問題了皇耗。 　　此外南窗，我的代碼 是具有 Unicode 意識的。那個(gè)操作注冊表的函數(shù)需要一個(gè)字節(jié)大小郎楼，使用lstrlen(Name+1) 得到的實(shí)際結(jié)果對于 Unicode 字符來說比 ANSI 字符要小一半万伤，而且它也不能從這個(gè)字符串的第二個(gè)字符起開始計(jì)算，也許你的本意是 lstrlen(Name) + 1（OK呜袁，我承認(rèn)敌买，我也犯了同樣的錯(cuò)誤！）阶界。不論如何虹钮，在 Unicode 模式下，所有的字符都是2個(gè)字節(jié)大小膘融，我們需要處理這個(gè)問題芙粱。微軟的文檔令人驚訝地對此保持緘默：REG_SZ 的值究竟是以字節(jié)計(jì)算還是以字符計(jì)算呢？我們假設(shè)它指的是以字節(jié)為單位計(jì)算氧映，你需要對你的代碼做一些修改來計(jì)算這個(gè)字符串所含有的字節(jié)大小春畔。 10、CString 的效率 　　CString 的一個(gè)問題是它確實(shí)掩藏了一些低效率的東西岛都。從另外一個(gè)方面講律姨，它也確實(shí)可以被實(shí)現(xiàn)得更加高效，你可能會(huì)說下面的代碼： 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ù)制操作。