CString 操作指南


原著：Joseph M. Newcomer

翻譯：littleloach

原文出處：codeproject：CString Management


通過閱讀本文你可以學習如何有效地使用 CString。

　　CString 是一種很有用的數(shù)據(jù)類型。它們很大程度上簡化了MFC中的許多操作，使得MFC在做字符串操作的時候方便了很多。不管怎樣，使用CString有很多特殊的技巧，特別是對于純C背景下走出來的程序員來說有點難以學習。這篇文章就來討論這些技巧。
　　使用CString可以讓你對字符串的操作更加直截了當。這篇文章不是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強制轉(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 和臨時對象；
10. CString 的效率；
11. 總結

下面我分別討論。

1、CString 對象的連接

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

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ù)來格式化一個字符串，還不如用 CString 對象的Format()方法：

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

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

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

　　我總是對我的字符串使用_T()宏，這是為了讓我的代碼至少有Unicode的意識，當然，關于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)境下，它的效果就相當于：

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

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

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

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

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需要一個字符個數(shù)作為參數(shù)，但是WriteFile卻需要字節(jié)數(shù)作為參數(shù)。
同樣需要注意的是有時候需要寫出數(shù)據(jù)的所有內(nèi)容。如果你僅僅只想寫出數(shù)據(jù)的真實長度，你可能會認為你應該這樣做：

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

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

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

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

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

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

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

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

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

CString graycat = "Gray" + "Cat";

或者這樣：

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

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

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

或者這樣：

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

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

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

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

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

char* 轉(zhuǎn)化為 CString

　　現(xiàn)在你有一個 char* 類型的數(shù)據(jù)，或者說一個字符串。怎么樣創(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;

結果字符串肯定是“GrayCat”。

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

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

CString s = "This is a test"; 

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

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

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

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

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

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

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

BOOL DoSomethingCool(LPCTSTR s);

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

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

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

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

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

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

"Mew! I love GrayCat"。

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

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

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

strcat(p, "each");

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

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

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

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

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

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

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

char buffer[1024];

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

LPTSTR p = s.GetBuffer(1024);

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

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

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

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

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

　　另外一個常見的錯誤是：既然固定大小的內(nèi)存不工作，那么就采用動態(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() 來包圍格式化字符串，但是基本 思路仍然是在走彎路，這這樣很容易出錯。

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

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

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

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

LPTSTR pszText;
int cchTextMax;

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

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

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

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

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

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

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

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

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

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

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

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

　　當我們使用 ActiveX 控件編程時，經(jīng)常需要用到將某個值表示成 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 指向的就是一個新分配的 BSTR 對象，該對象是 CString 的一個拷貝，包含終結 NULL字符?，F(xiàn)在你可以將它傳遞給任何需要 BSTR 的接口。通常，BSTR 由接收它的組件來釋放，如果你需要自己釋放 BSTR 的話，可以這么做：

::SysFreeString(b);

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

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

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

例如，在一個ANSI程序中：

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

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

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

CString::CString(LPCTSTR);

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

CString::CString(LPCWSTR); 

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

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";

　　你應該把你所有特定語言的字符串單獨擺放（調(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); 

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

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

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

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

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

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

9、CString 和臨時對象

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

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

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

真讓人困惑，請幫幫我。

親愛的 Frustrated，

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

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);

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

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

CString cat("Mew!");

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

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

則每一個 + 的應用會造成一個新的字符串被創(chuàng)建和一次復制操作。

總結

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