通過閱讀本文你可以學習如何有效地使用CString。
CString 是一種很有用的數據類型。它們很大程度上簡化了MFC中的許多操作，使得MFC在做字符串操作的時候方便了很多。不管怎樣，使用CString有很多特殊的技巧，特別是對於純C背景下走出來的程序員來說有點難以學習。這篇文章就來討論這些技巧。
使用CString可以讓你對字符串的操作更加直截了當。這篇文章不是CString的完全手冊，但囊括了大部分常見基本問題。
下面我分別討論。
1、CString 對象的連接
能體現出 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() 函數或 wsprintf() 函數來格式化一個字符串，還不如用 CString 對象的Format()方法：
CString s;
s.Format(_T("The total is %d"), total);
用這種方法的好處是你不用擔心用來存放格式化後數據的緩沖區是否足夠大，這些工作由CString類替你完成。
格式化是一種把其它不是字符串類型的數據轉化為CString類型的最常用技巧，比如，把一個整數轉化成CString類型，可用如下方法：
CString s;
s.Format(_T("%d"), total);
我總是對我的字符串使用_T()宏，這是為了讓我的代碼至少有Unicode的意識，當然，關於Unicode的話題不在這篇文章的討論范圍。_T()宏在8位字符環境下是如下定義的：
#define _T(x) x // 非Unicode版本（non-Unicode version）
而在Unicode環境下是如下定義的：
#define _T(x) L##x // Unicode版本（Unicode version）
所以在Unicode環境下，它的效果就相當於：
s.Format(L"%d", total);
如果你認為你的程序可能在Unicode的環境下運行，那麼開始在意用 Unicode 編碼。比如說，不要用 sizeof() 操作符來獲得字符串的長度，因為在Unicode環境下就會有2倍的誤差。我們可以用一些方法來隱藏Unicode的一些細節，比如在我需要獲得字符長度的時候，我會用一個叫做DIM的宏，這個宏是在我的dim.h文件中定義的，我會在我寫的所有程序中都包含這個文件：
#define DIM(x) ( sizeof((x)) / sizeof((x)[0]) )
這個宏不僅可以用來解決Unicode的字符串長度的問題，也可以用在編譯時定義的表格上，它可以獲得表格的項數，如下：
class Whatever { ... };
Whatever data[] = {
{ ... },
...
{ ... },
};
for(int i = 0; i < DIM(data); i++) // 掃描表格尋找匹配項。
這裡要提醒你的就是一定要注意那些在參數中需要真實字節數的API函數調用，如果你傳遞字符個數給它，它將不能正常工作。如下：
TCHAR data[20];
lstrcpyn(data, longstring, sizeof(data) - 1); // WRONG!
lstrcpyn(data, longstring, DIM(data) - 1); // RIGHT
WriteFile(f, data, DIM(data), &bytesWritten, NULL); // WRONG!
WriteFile(f, data, sizeof(data), &bytesWritten, NULL); // RIGHT
造成以上原因是因為lstrcpyn需要一個字符個數作為參數，但是WriteFile卻需要字節數作為參數。
同樣需要注意的是有時候需要寫出數據的所有內容。如果你僅僅只想寫出數據的真實長度，你可能會認為你應該這樣做：
WriteFile(f, data, lstrlen(data), &bytesWritten, NULL); // WRONG
但是在Unicode環境下，它不會正常工作。正確的做法應該是這樣：
WriteFile(f, data, lstrlen(data) * sizeof(TCHAR), &bytesWritten, NULL); // RIGHT
因為WriteFile需要的是一個以字節為單位的長度。（可能有些人會想“在非Unicode的環境下運行這行代碼，就意味著總是在做一個多余的乘1操作，這樣不會降低程序的效率嗎？”這種想法是多余的，你必須要了解編譯器實際上做了什麼，沒有哪一個C或C++編譯器會把這種無聊的乘1操作留在代碼中。在Unicode環境下運行的時候，你也不必擔心那個乘2操作會降低程序的效率，記住，這只是一個左移一位的操作而已，編譯器也很樂意為你做這種替換。）
使用_T宏並不是意味著你已經創建了一個Unicode的程序，你只是創建了一個有Unicode意識的程序而已。如果你在默認的8-bit模式下編譯你的程序的話，得到的將是一個普通的8-bit的應用程序（這裡的8-bit指的只是8位的字符編碼，並不是指8位的計算機系統）；當你在Unicode環境下編譯你的程序時，你才會得到一個Unicode的程序。記住，CString 在 Unicode 環境下，裡面包含的可都是16位的字符哦。
3、CString 型轉化成 int 型
把 CString 類型的數據轉化成整數類型最簡單的方法就是使用標准的字符串到整數轉換例程。
雖然通常你懷疑使用_atoi()函數是一個好的選擇，它也很少會是一個正確的選擇。如果你准備使用 Unicode 字符，你應該用_ttoi()，它在 ANSI 編碼系統中被編譯成_atoi()，而在 Unicode 編碼系統中編譯成_wtoi()。你也可以考慮使用_tcstoul()或者_tcstol()，它們都能把字符串轉化成任意進制的長整數（如二進制、八進制、十進制或十六進制），不同點在於前者轉化後的數據是無符號的（unsigned），而後者相反。看下面的例子：
CString hex = _T("FAB");
CString decimal = _T("4011");
ASSERT(_tcstoul(hex, 0, 16) == _ttoi(decimal));
4、CString 型和 char* 類型的相互轉化
這是初學者使用 CString 時最常見的問題。有了 C++ 的幫助，很多問題你不需要深入的去考慮它，直接拿來用就行了，但是如果你不能深入了解它的運行機制，又會有很多問題讓你迷惑，特別是有些看起來沒有問題的代碼，卻偏偏不能正常工作。
比如，你會奇怪為什麼不能寫向下面這樣的代碼呢：
CString graycat = "Gray" + "Cat";
或者這樣：
CString graycat("Gray" + "Cat");
事實上，編譯器將抱怨上面的這些嘗試。為什麼呢？因為針對CString 和 LPCTSTR數據類型的各種各樣的組合，“ +” 運算符 被定義成一個重載操作符。而不是兩個 LPCTSTR 數據類型，它是底層數據類型。你不能對基本數據（如 int、char 或者 char*）類型重載 C++ 的運算符。你可以象下面這樣做：
CString graycat = CString("Gray") + CString("Cat");
或者這樣：
CString graycat = CString("Gray") + "Cat";
研究一番就會發現：“ +”總是使用在至少有一個 CString 對象和一個 LPCSTR 的場合。
注意，編寫有 Unicode 意識的代碼總是一件好事，比如：
CString graycat = CString(_T("Gray")) + _T("Cat");
這將使得你的代碼可以直接移植。
char* 轉化為 CString
現在你有一個 char* 類型的數據，或者說一個字符串。怎麼樣創建 CString 對象呢？這裡有一些例子：
char * p = "This is a test";
或者象下面這樣更具有 Unicode 意識：
TCHAR * p = _T("This is a test")
或
LPTSTR p = _T("This is a test");
你可以使用下面任意一種寫法：
CString s = "This is a test"; // 8-bit 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);
用這些方法可以輕松將常量字符串或指針轉換成 CString。需要注意的是，字符的賦值總是被拷貝到 CString 對象中去的，所以你可以象下面這樣操作：
TCHAR * p = _T("Gray");
CString s(p);
p = _T("Cat");
s += p;
結果字符串肯定是“GrayCat”。
CString 類還有幾個其它的構造函數，但是這裡我們不考慮它，如果你有興趣可以自己查看相關文檔。
事實上，CString 類的構造函數比我展示的要復雜，比如：
CString s = "This is a test";
這是很草率的編碼，但是實際上它在 Unicode 環境下能編譯通過。它在運行時調用構造函數的 MultiByteToWideChar 操作將 8 位字符串轉換成 16 位字符串。不管怎樣，如果 char * 指針是網絡上傳輸的 8 位數據，這種轉換是很有用的。
CString 轉化成 char* 之一：強制類型轉換為 LPCTSTR；
這是一種略微硬性的轉換，有關“正確”的做法，人們在認識上還存在許多混亂，正確的使用方法有很多，但錯誤的使用方法可能與正確的使用方法一樣多。
我們首先要了解 CString 是一種很特殊的 C++ 對象，它裡面包含了三個值：一個指向某個數據緩沖區的指針、一個是該緩沖中有效的字符記數以及一個緩沖區長度。 有效字符數的大小可以是從0到該緩沖最大長度值減1之間的任何數（因為字符串結尾有一個NULL字符）。字符記數和緩沖區長度被巧妙隱藏。
除非你做一些特殊的操作，否則你不可能知道給CString對象分配的緩沖區的長度。這樣，即使你獲得了該0緩沖的地址，你也無法更改其中的內容，不能截短字符串，也 絕對沒有辦法加長它的內容，否則第一時間就會看到溢出。
LPCTSTR 操作符（或者更明確地說就是 TCHAR * 操作符）在 CString 類中被重載了，該操作符的定義是返回緩沖區的地址，因此，如果你需要一個指向 CString 的 字符串指針的話，可以這樣做：
CString s("GrayCat");
LPCTSTR p = s;
它可以正確地運行。這是由C語言的強制類型轉化規則實現的。當需要強制類型轉化時，C++規測容許這種選擇。比如，你可以將（浮點數）定義為將某個復數 （有一對浮點數）進行強制類型轉換後只返回該復數的第一個浮點數（也就是其實部）。可以象下面這樣：
Complex c(1.2f, 4.8f);
float realpart = c;
如果(float)操作符定義正確的話，那麼實部的的值應該是1.2。
這種強制轉化適合所有這種情況，例如，任何帶有 LPCTSTR 類型參數的函數都會強制執行這種轉換。 於是，你可能有這樣一個函數（也許在某個你買來的DLL中）：
BOOL DoSomethingCool(LPCTSTR s);
你象下面這樣調用它：
CString file("c:\\myfiles\\coolstuff")
BOOL result = DoSomethingCool(file);
它能正確運行。因為 DoSomethingCool 函數已經說明了需要一個 LPCTSTR 類型的參數，因此 LPCTSTR 被應用於該參數，在 MFC 中就是返回的串地址。
如果你要格式化字符串怎麼辦呢？
CString graycat("GrayCat");
CString s;
s.Format("Mew! I love %s", graycat);
注意由於在可變參數列表中的值（在函數說明中是以“...”表示的）並沒有隱含一個強制類型轉換操作符。你會得到什麼結果呢？
一個令人驚訝的結果，我們得到的實際結果串是：
"Mew! I love GrayCat"。
因為 MFC 的設計者們在設計 CString 數據類型時非常小心， CString 類型表達式求值後指向了字符串，所以這裡看不到任何象 Format 或 sprintf 中的強制類型轉換，你仍然可以得到正確的行為。描述 CString 的附加數據實際上在 CString 名義地址之後。
有一件事情你是不能做的，那就是修改字符串。比如，你可能會嘗試用“,”代替“.”（不要做這樣的，如果你在乎國際化問題，你應該使用十進制轉換的 National Language Support 特性，），下面是個簡單的例子：
CString v("1.00"); // 貨幣金額，兩位小數
LPCTSTR p = v;
p[lstrlen(p) - 3] = '','';
這時編譯器會報錯，因為你賦值了一個常量串。如果你做如下嘗試，編譯器也會錯：
strcat(p, "each");
因為 strcat 的第一個參數應該是 LPTSTR 類型的數據，而你卻給了一個 LPCTSTR。
不要試圖鑽這個錯誤消息的牛角尖，這只會使你自己陷入麻煩！
原因是緩沖有一個計數，它是不可存取的（它位於 CString 地址之下的一個隱藏區域），如果你改變這個串，緩沖中的字符計數不會反映所做的修改。此外，如果字符串長度恰好是該字符串物理限制的長度（梢後還會講到這個問題），那麼擴展該字符串將改寫緩沖以外的任何數據，那是你無權進行寫操作的內存（不對嗎？），你會毀換壞不屬於你的內存。這是應用程序真正的死亡處方。
CString轉化成char* 之二：使用 CString 對象的 GetBuffer 方法；
如果你需要修改 CString 中的內容，它有一個特殊的方法可以使用，那就是 GetBuffer，它的作用是返回一個可寫的緩沖指針。 如果你只是打算修改字符或者截短字符串，你完全可以這樣做：
CString s(_T("File.ext"));
LPTSTR p = s.GetBuffer();
LPTSTR dot = strchr(p, ''.''); // OK, should have used s.Find...
if(p != NULL)
*p = _T(''\0'');
s.ReleaseBuffer();
這是 GetBuffer 的第一種用法，也是最簡單的一種，不用給它傳遞參數，它使用默認值 0，意思是：“給我這個字符串的指針，我保證不加長它”。當你調用 ReleaseBuffer 時，字符串的實際長度會被重新計算，然後存入 CString 對象中。
必須強調一點，在 GetBuffer 和 ReleaseBuffer 之間這個范圍，一定不能使用你要操作的這個緩沖的 CString 對象的任何方法。因為 ReleaseBuffer 被調用之前，該 CString 對象的完整性得不到保障。研究以下代碼：
CString s(...);
LPTSTR p = s.GetBuffer();
//... 這個指針 p 發生了很多事情
int n = s.GetLength(); // 很糟D!!!!! 有可能給出錯誤的答案!!!
s.TrimRight(); // 很糟!!!!! 不能保證能正常工作!!!!
s.ReleaseBuffer(); // 現在應該 OK
int m = s.GetLength(); // 這個結果可以保證是正確的。
s.TrimRight(); // 將正常工作。
假設你想增加字符串的長度，你首先要知道這個字符串可能會有多長，好比是聲明字符串數組的時候用：
char buffer[1024];
表示 1024 個字符空間足以讓你做任何想做得事情。在 CString 中與之意義相等的表示法：
LPTSTR p = s.GetBuffer(1024);
調用這個函數後，你不僅獲得了字符串緩沖區的指針，而且同時還獲得了長度至少為 1024 個字符的空間（注意，我說的是“字符”，而不是“字節”，因為 CString 是以隱含方式感知 Unicode 的）。
同時，還應該注意的是，如果你有一個常量串指針，這個串本身的值被存儲在只讀內存中，如果試圖存儲它，即使你已經調用了 GetBuffer ，並獲得一個只讀內存的指針，存入操作會失敗，並報告存取錯誤。我沒有在 CString 上證明這一點，但我看到過大把的 C 程序員經常犯這個錯誤。
C 程序員有一個通病是分配一個固定長度的緩沖，對它進行 sprintf 操作，然後將它賦值給一個 CString：
char buffer[256];
sprintf(buffer, "%......", args, ...); // ... 部分省略許多細節
CString s = buffer;
雖然更好的形式可以這麼做：
CString s;
s.Format(_T("%...."), args, ...);
如果你的字符串長度萬一超過 256 個字符的時候，不會破壞堆棧。
另外一個常見的錯誤是：既然固定大小的內存不工作，那麼就采用動態分配字節，這種做法弊端更大：
int len = lstrlen(parm1) + 13 lstrlen(parm2) + 10 + 100;
char * buffer = new char[len];
sprintf(buffer, "%s is equal to %s, valid data", parm1, parm2);
CString s = buffer;
......
delete [] buffer;
它可以能被簡單地寫成：
CString s;
s.Format(_T("%s is equal to %s, valid data"), parm1, parm2);
需要注意 sprintf 例子都不是 Unicode 就緒的，盡管你可以使用 tsprintf 以及用 _T() 來包圍格式化字符串，但是基本 思路仍然是在走彎路，這這樣很容易出錯。
CString to char * 之三：和控件的接口；
我們經常需要把一個 CString 的值傳遞給一個控件，比如，CTreeCtrl。MFC為我們提供了很多便利來重載這個操作，但是 在大多數情況下，你使用“原始”形式的更新，因此需要將墨某個串指針存儲到 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 類型的變量，而且編譯器無法知道如何將賦值語句右邊強制轉換成 LPCTSTR。好吧，你說，那我就改成這樣：
tvi.item.pszText = (LPCTSTR)s; //編譯器依然會報錯。
編譯器之所以依然報錯是因為你試圖把一個 LPCTSTR 類型的變量賦值給一個 LPTSTR 類型的變量，這種操作在C或C++中是被禁止的。你不能用這種方法 來濫用常量指針與非常量指針概念，否則，會擾亂編譯器的優化機制，使之不知如何優化你的程序。比如，如果你這麼做：
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] 的位置也是常量，這樣間接地破壞了先前的假設。因此，你的程序將會在 debug 編譯模式（沒有優化）和 release 編譯模式（完全優化）中反映出不同的行為，這種情況可不好，所以當你試圖把指向 i 的指針賦值給一個 可修改的引用時，會被編譯器診斷為這是一種偽造。這就是為什麼（LPCTSTR）強制類型轉化不起作用的原因。
為什麼不把該成員聲明成 LPCTSTR 類型呢？因為這個結構被用於讀寫控件。當你向控件寫數據時，文本指針實際上被當成 LPCTSTR，而當你從控件讀數據 時，你必須有一個可寫的字符串。這個結構無法區分它是用來讀還是用來寫。
因此，你會常常在我的代碼中看到如下的用法：
tvi.item.pszText = (LPTSTR)(LPCTSTR)s;
它把 CString 強制類型轉化成 LPCTSTR，也就是說先獲得改字符串的地址，然後再強制類型轉化成 LPTSTR，以便可以對之進行賦值操作。 注意這只有在使用 Set 或 Insert 之類的方法才有效！如果你試圖獲取數據，則不能這麼做。
如果你打算獲取存儲在控件中的數據，則方法稍有不同，例如，對某個 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方法）不會改變字符串的內容。但是當你需要寫 CString 對象時，必須保證緩沖是可寫的，這正是 GetBuffer 所做的事情。再次強調： 一旦做了一次 GetBuffer 調用，那麼在調用 ReleaseBuffer 之前不要對這個 CString 對象做任何操作。
5、CString 型轉化成 BSTR 型
當我們使用 ActiveX 控件編程時，經常需要用到將某個值表示成 BSTR 類型。BSTR 是一種記數字符串，Intel平台上的寬字符串（Unicode），並且 可以包含嵌入的 NULL 字符。
你可以調用 CString 對象的 AllocSysString 方法將 CString 轉化成 BSTR：
CString s;
s = ... ; // whatever
BSTR b = s.AllocSysString();
現在指針 b 指向的就是一個新分配的 BSTR 對象，該對象是 CString 的一個拷貝，包含終結 NULL字符。現在你可以將它傳遞給任何需要 BSTR 的接口。通常，BSTR 由接收它的組件來釋放，如果你需要自己釋放 BSTR 的話，可以這麼做：
::SysFreeString(b);
對於如何表示傳遞給 ActiveX 控件的字符串，在微軟內部曾一度爭論不休，最後 Visual Basic 的人占了上風，BSTR（“Basic String”的首字母縮寫）就是這場爭論的結果。
6、BSTR 型轉化成 CString 型
由於 BSTR 是記數 Unicode 字符串，你可以用標准轉換方法來創建 8 位的 CString。實際上，這是 CString 內建的功能。在 CString 中 有特殊的構造函數可以把 ANSI 轉化成 Unicode，也可以把Unicode 轉化成 ANSI。你同樣可以從 VARIANT 類型的變量中獲得 BSTR 類型的字符串，VARIANT 類型是 由各種 COM 和 Automation (自動化)調用返回的類型。
例如，在一個ANSI程序中：
BSTR b;
b = ...; // whatever
CString s(b == NULL ? L"" : b)
對於單個的 BSTR 串來說，這種用法可以工作得很好，這是因為 CString 有一個特殊的構造函數以LPCWSTR（BSTR正是這種類型） 為參數，並將它轉化成 ANSI 類型。專門檢查是必須的，因為 BSTR 可能為空值，而 CString 的構造函數對於 NULL 值情況考慮的不是很周到，（感謝 Brian Ross 指出這一點!）。這種用法也只能處理包含 NUL 終結字符的單字符串；如果要轉化含有多個 NULL 字符 串，你得額外做一些工作才行。在 CString 中內嵌的 NULL 字符通常表現不盡如人意，應該盡量避免。
根據 C/C++ 規則，如果你有一個 LPWSTR，那麼它別無選擇，只能和 LPCWSTR 參數匹配。
在 Unicode 模式下，它的構造函數是：
CString::CString(LPCTSTR);
正如上面所表示的，在 ANSI 模式下，它有一個特殊的構造函數：
CString::CString(LPCWSTR);
它會調用一個內部的函數將 Unicode 字符串轉換成 ANSI 字符串。（在Unicode模式下，有一個專門的構造函數，該函數有一個參數是LPCSTR類型——一個8位 ANSI 字符串 指針，該函數將它加寬為 Unicode 的字符串！）再次強調：一定要檢查 BSTR 的值是否為 NULL。
另外還有一個問題，正如上文提到的：BSTRs可以含有多個內嵌的NULL字符，但是 CString 的構造函數只能處理某個串中單個 NULL 字符。 也就是說，如果串中含有嵌入的 NUL字節，CString 將會計算出錯誤的串長度。你必須自己處理它。如果你看看 strcore.cpp 中的構造函數，你會發現 它們都調用了lstrlen，也就是計算字符串的長度。
注意從 Unicode 到 ANSI 的轉換使用帶專門參數的 ::WideCharToMultiByte，如果你不想使用這種默認的轉換方式，則必須編寫自己的轉化代碼。
如果你在 UNICODE 模式下編譯代碼，你可以簡單地寫成：
CString convert(BSTR b)
{
if(b == NULL)
return CString(_T(""));
CString s(b); // in UNICODE mode
return s;
}
如果是 ANSI 模式，則需要更復雜的過程來轉換。注意這個代碼使用與 ::WideCharToMultiByte 相同的參數值。所以你 只能在想要改變這些參數進行轉換時使用該技術。例如，指定不同的默認字符，不同的標志集等。
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;
}
我並不擔心如果 BSTR 包含沒有映射到 8 位字符集的 Unicode 字符時會發生什麼，因為我指定了::WideCharToMultiByte 的最後兩個參數為 NULL。這就是你可能需要改變的地方。
7、VARIANT 型轉化成 CString 型
事實上，我從來沒有這麼做過，因為我沒有用 COM/OLE/ActiveX 編寫過程序。但是我在microsoft.public.vc.mfc 新聞組上看到了 Robert Quirk 的一篇帖子談到了這種轉化，我覺得把他的文章包含在我的文章裡是不太好的做法，所以在這裡多做一些解釋和演示。如果和他的文章有相孛的地方可能是我的疏忽。
VARIANT 類型經常用來給 COM 對象傳遞參數，或者接收從 COM 對象返回的值。你也能自己編寫返回 VARIANT 類型的方法，函數返回什麼類型 依賴可能（並且常常）方法的輸入參數（比如，在自動化操作中，依賴與你調用哪個方法。IDispatch::Invoke 可能返回（通過其一個參數）一個 包含有BYTE、WORD、float、double、date、BSTR 等等 VARIANT 類型的結果，（詳見 MSDN 上的 VARIANT 結構的定義）。在下面的例子中，假設 類型是一個BSTR的變體，也就是說在串中的值是通過 bsrtVal 來引用，其優點是在 ANSI 應用中，有一個構造函數會把 LPCWCHAR 引用的值轉換為一個 CString（見 BSTR-to-CString 部分）。在 Unicode 模式中，將成為標准的 CString 構造函數，參見對缺省::WideCharToMultiByte 轉換的告誡，以及你覺得是否可以接受（大多數情況下，你會滿意的）。
VARIANT vaData;
vaData = m_com.YourMethodHere();
ASSERT(vaData.vt == VT_BSTR);
CString strData(vaData.bstrVal);
你還可以根據 vt 域的不同來建立更通用的轉換例程。為此你可能會考慮：
CString VariantToString(VARIANT * va)
{
CString s;
switch(va->vt)
{ /* vt */
case VT_BSTR:
return CString(vaData->bstrVal);
case VT_BSTR | VT_BYREF:
return CString(*vaData->pbstrVal);
case VT_I4:
s.Format(_T("%d"), va->lVal);
return s;
case VT_I4 | VT_BYREF:
s.Format(_T("%d"), *va->plVal);
case VT_R8:
s.Format(_T("%f"), va->dblVal);
return s;
... 剩下的類型轉換由讀者自己完成
default:
ASSERT(FALSE); // unknown VARIANT type (this ASSERT is optional)
return CString("");
} /* vt */
}
8、載入字符串表資源
如果你想創建一個容易進行語言版本移植的應用程序，你就不能在你的源代碼中直接包含本土語言字符串 （下面這些例子我用的語言都是英語，因為我的本土語是英語），比如下面這種寫法就很糟：
CString s = "There is an error";
你應該把你所有特定語言的字符串單獨擺放（調試信息、在發布版本中不出現的信息除外）。這意味著向下面這樣寫比較好：
s.Format(_T("%d - %s"), code, text);
在你的程序中，文字字符串不是語言敏感的。不管怎樣，你必須很小心，不要使用下面這樣的串：
// fmt is "Error in %s file %s"
// readorwrite is "reading" or "writing"
s.Format(fmt, readorwrite, filename);
這是我的切身體會。在我的第一個國際化的應用程序中我犯了這個錯誤，盡管我懂德語，知道在德語的語法中動詞放在句子的最後面，我們的德國方面的發行人還是苦苦的抱怨他們不得不提取那些不可思議的德語錯誤提示信息然後重新格式化以讓它們能正常工作。比較好的辦法（也是我現在使用的辦法）是使用兩個字符串，一個用 於讀，一個用於寫，在使用時加載合適的版本，使得它們對字符串參數是非敏感的。也就是說加載整個格式，而不是加載串“reading”，“writing”：
// fmt is "Error in reading file %s"
// "Error in writing file %s"
s.Format(fmt, filename);
一定要注意，如果你有好幾個地方需要替換，你一定要保證替換後句子的結構不會出現問題，比如在英語中，可以是主語-賓語，主語-謂語，動詞-賓語的結構等等。
在這裡，我們並不討論 FormatMessage，其實它比 sprintf/Format 還要有優勢，但是不太容易和CString 結合使用。解決這種問題的辦法就是我們按照參數出現在參數表中的位置給參數取名字，這樣在你輸出的時候就不會把他們的位置排錯了。
接下來我們討論我們這些獨立的字符串放在什麼地方。我們可以把字符串的值放入資源文件中的一個稱為 STRINGTABLE 的段中。過程如下：首先使用 Visual Studio 的資源編輯器創建一個字符串，然後給每一個字符串取一個ID，一般我們給它取名字都以 IDS_開頭。所以如果你有一個信息，你可以創建一個字符串資源然後取名為 IDS_READING_FILE，另外一個就取名為 IDS_WRITING_FILE。它們以下面的形式出現在你的 .rc 文件中：
STRINGTABLE
IDS_READING_FILE "Reading file %s"
IDS_WRITING_FILE "Writing file %s"
END
注意：這些資源都以 Unicode 的格式保存，不管你是在什麼環境下編譯。他們在Win9x系統上也是以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);
現在，你的代碼可以移植到任何語言中去。LoadString 方法需要一個字符串資源的 ID 作為參數，然後它從 STRINGTABLE 中取出它對應的字符串，賦值給 CString 對象。 CString 對象的構造函數還有一個更加聰明的特征可以簡化 STRINGTABLE 的使用。這個用法在 CString::CString 的文檔中沒有指出，但是在 構造函數的示例程序中使用了。（為什麼這個特性沒有成為正式文檔的一部分，而是放在了一個例子中，我記不得了！）——【譯者注：從這句話看，作者可能是CString的設計者。其實前面還有一句類似的話。說他沒有對使用GetBuffer(0)獲得的指針指向的地址是否可讀做有效性檢查 】。這個特征就是：如果你將一個字符串資源的ID強制類型轉換為 LPCTSTR，將會隱含調用 LoadString。因此，下面兩個構造字符串的例子具有相同的效果，而且其 ASSERT 在debug模式下不會被觸發：
CString s;
s.LoadString(IDS_WHATEVER);
CString t( (LPCTSTR)IDS_WHATEVER );
ASSERT(s == t);//不會被觸發，說明s和t是相同的。
現在，你可能會想：這怎麼可能工作呢？我們怎麼能把 STRINGTABLE ID 轉化成一個指針呢？很簡單：所有的字符串 ID 都在1~65535這個范圍內，也就是說，它所有的高位都是0，而我們在程序中所使用的指針是不可能小於65535的，因為程序的低 64K 內存永遠也不可能存在的，如果你試圖訪問0x00000000到0x0000FFFF之間的內存，將會引發一個內存越界錯誤。所以說1~65535的值不可能是一個內存地址，所以我們可以用這些值來作為字符串資源的ID。
我傾向於使用 MAKEINTRESOURCE 宏顯式地做這種轉換。我認為這樣可以讓代碼更加易於閱讀。這是個只適合在 MFC 中使用的標准宏。你要記住，大多數的方法即可以接受一個 UINT 型的參數，也可以接受一個 LPCTSTR 型的參數，這是依賴 C++ 的重載功能做到的。C++重載函數帶來的 弊端就是造成所有的強制類型轉化都需要顯示聲明。同樣，你也可以給很多種結構只傳遞一個資源名。
CString s;
s.LoadString(IDS_WHATEVER);
CString t( MAKEINTRESOURCE(IDS_WHATEVER));
ASSERT(s == t);
告訴你吧：我不僅只是在這裡鼓吹，事實上我也是這麼做的。在我的代碼中，你幾乎不可能找到一個字符串，當然，那些只是偶然在調試中出現的或者和語言無關的字符串除外。
9、CString 和臨時對象
這是出現在 microsoft.public.vc.mfc 新聞組中的一個小問題，我簡單的提一下，這個問題是有個程序員需要往注冊表中寫入一個字符串，他寫道：
我試著用 RegSetValueEx() 設置一個注冊表鍵的值，但是它的結果總是令我困惑。當我用char[]聲明一個變量時它能正常工作，但是當我用 CString 的時候，總是得到一些垃圾："ÝÝÝÝ...ÝÝÝÝÝÝ"為了確認是不是我的 CString 數據出了問題，我試著用 GetBuffer，然後強制轉化成 char*，LPCSTR。GetBuffer 返回的值是正確的，但是當我把它賦值給 char* 時，它就變成垃圾了。以下是我的程序段：
char* szName = GetName().GetBuffer(20);
RegSetValueEx(hKey, "Name", 0, REG_SZ,
(CONST BYTE *) szName,
strlen (szName + 1));
這個 Name 字符串的長度小於 20，所以我不認為是 GetBuffer 的參數的問題。
真讓人困惑，請幫幫我。
親愛的 Frustrated，
你犯了一個相當微妙的錯誤，聰明反被聰明誤，正確的代碼應該象下面這樣：
CString Name = GetName();
RegSetValueEx(hKey, _T("Name"), 0, REG_SZ,
(CONST BYTE *) (LPCTSTR)Name,
(Name.GetLength() + 1) * sizeof(TCHAR));
為什麼我寫的代碼能行而你寫的就有問題呢？主要是因為當你調用 GetName 時返回的 CString 對象是一個臨時對象。參見：《C++ Reference manual》§12.2
在一些環境中，編譯器有必要創建一個臨時對象，這樣引入臨時對象是依賴於實現的。如果編譯器引入的這個臨時對象所屬的類有構造函數的話，編譯器要確保這個類的構造函數被調用。同樣的，如果這個類聲明有析構函數的話，也要保證這個臨時對象的析構函數被調用。
編譯器必須保證這個臨時對象被銷毀了。被銷毀的確切地點依賴於實現.....這個析構函數必須在退出創建該臨時對象的范圍之前被調用。
大部分的編譯器是這樣設計的：在臨時對象被創建的代碼的下一個執行步驟處隱含調用這個臨時對象的析構函數，實現起來，一般都是在下一個分號處。因此，這個 CString 對象在 GetBuffer 調用之後就被析構了（順便提一句，你沒有理由給 GetBuffer 函數傳遞一個參數，而且沒有使用ReleaseBuffer 也是不對的）。所以 GetBuffer 本來返回的是指向這個臨時對象中字符串的地址的指針，但是當這個臨時對象被析構後，這塊內存就被釋放了。然後 MFC 的調試內存分配器會重新為這塊內存全部填上 0xDD，顯示出來剛好就是“Ý”符號。在這個時候你向注冊表中寫數據，字符串的內容當然全被破壞了。
我們不應該立即把這個臨時對象轉化成 char* 類型，應該先把它保存到一個 CString 對象中，這意味著把臨時對象復制了一份，所以當臨時的 CString 對象被析構了之後，這個 CString 對象中的值依然保存著。這個時候再向注冊表中寫數據就沒有問題了。
此外，我的代碼是具有 Unicode 意識的。那個操作注冊表的函數需要一個字節大小，使用lstrlen(Name+1) 得到的實際結果對於 Unicode 字符來說比 ANSI 字符要小一半，而且它也不能從這個字符串的第二個字符起開始計算，也許你的本意是 lstrlen(Name) + 1（OK，我承認，我也犯了同樣的錯誤！）。不論如何，在 Unicode 模式下，所有的字符都是2個字節大小，我們需要處理這個問題。微軟的文檔令人驚訝地對此保持緘默：REG_SZ 的值究竟是以字節計算還是以字符計算呢？我們假設它指的是以字節為單位計算，你需要對你的代碼做一些修改來計算這個字符串所含有的字節大小。
10、CString 的效率
CString 的一個問題是它確實掩藏了一些低效率的東西。從另外一個方面講，它也確實可以被實現得更加高效，你可能會說下面的代碼：
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 分配一塊內存，然後把 SomeCString1 復制到裡面，然後發現它要做一個連接，則重新分配一塊新的足夠大的內存，大到能夠放下當前的字符串加上SomeCString2，把內容復制到這塊內存 ，然後把 SomeCString2 連接到後面，然後釋放第一塊內存，並把指針重新指向新內存。然後為每個字符串重復這個過程。把這 4 個字符串連接起來效率多低啊。事實上，在很多情況下根本就不需要復制源字符串（在 += 操作符左邊的字符串）。
在 VC++6.0 中，Release 模式下，所有的 CString 中的緩存都是按預定義量子分配的。所謂量子，即確定為 64、128、256 或者 512 字節。這意味著除非字符串非常長，連接字符串的操作實際上就是 strcat 經過優化後的版本（因為它知道本地的字符串應該在什麼地方結束，所以不需要尋找字符串的結尾；只需要把內存中的數據拷貝到指定的地方即可）加上重新計算字符串的長度。所以它的執行效率和純 C 的代碼是一樣的，但是它更容易寫、更容易維護和更容易理解。
如果你還是不能確定究竟發生了怎樣的過程，請看看 CString 的源代碼，strcore.cpp，在你 vc98的安裝目錄的 mfc\src 子目錄中。看看 ConcatInPlace 方法，它被在所有的 += 操作符中調用。
啊哈！難道 CString 真的這麼"高效"嗎？比如，如果我創建
CString cat("Mew!");
然後我並不是得到了一個高效的、精簡的5個字節大小的緩沖區（4個字符加一個結束字符），系統將給我分配64個字節，而其中59個字節都被浪費了。
如果你也是這麼想的話，那麼就請准備好接受再教育吧。可能在某個地方某個人給你講過盡量使用少的空間是件好事情。不錯，這種說法的確正確，但是他忽略了事實中一個很重要的方面。
如果你編寫的是運行在16K EPROMs下的嵌入式程序的話，你有理由盡量少使用空間，在這種環境下，它能使你的程序更健壯。但是在 500MHz, 256MB的機器上寫 Windows 程序，如果你還是這麼做，它只會比你認為的“低效”的代碼運行得更糟。
舉例來說。字符串的大小被認為是影響效率的首要因素，使字符串盡可能小可以提高效率，反之則降低效率，這是大家一貫的想法。但是這種想法是不對的，精確的內存分配的後果要在程序運行了好幾個小時後才能體現得出來，那時，程序的堆中將充滿小片的內存，它們太小以至於不能用來做任何事，但是他們增加了你程序的內存用量，增加了內存頁面交換的次數，當頁面交換的次數增加到系統能夠忍受的上限，系統則會為你的程序分配更多的頁面，直到你的程序占用了所有的可用內存。由此可見，雖然內存碎片是決定效率的次要因素，但正是這些因素實際控制了系統的行為，最終，它損害了系統的可靠性，這是令人無法接受的。
記住，在 debug 模式下，內存往往是精確分配的，這是為了更好的排錯。
假設你的應用程序通常需要連續工作好幾個月。比如，我常打開 VC++，Word，PowerPoint，Frontpage，Outlook Express，Forté Agent，Internet Explorer和其它的一些程序，而且通常不關閉它們。我曾經夜以繼日地連續用 PowerPoint 工作了好幾天（反之，如果你不幸不得不使用像 Adobe FrameMaker 這樣的程序的話，你將會體會到可靠性的重要；這個程序機會每天都要崩潰4~6次，每次都是因為用完了所有的空間並填滿我所有的交換頁面）。所以精確內存分配是不可取的，它會危及到系統的可靠性，並引起應用程序崩潰。
按量子的倍數為字符串分配內存，內存分配器就可以回收用過的內存塊，通常這些回收的內存塊馬上就可以被其它的 CString 對象重新用到，這樣就可以保證碎片最少。分配器的功能加強了，應用程序用到的內存就能盡可能保持最小，這樣的程序就可以運行幾個星期或幾個月而不出現問題。
題外話：很多年以前，我們在 CMU 寫一個交互式系統的時候，一些對內存分配器的研究顯示出它往往產生很多內存碎片。Jim Mitchell，現在他在 Sun Microsystems 工作，那時侯他創造了一種內存分配器，它保留了一個內存分配狀況的運行時統計表，這種技術和當時的主流分配器所用的技術都不同，且較為領先。當一個內存塊需要被分割得比某一個值小的話，他並不分割它，因此可以避免產生太多小到什麼事都干不了的內存碎片。事實上他在內存分配器中使用了一個浮動指針，他認為：與其讓指令做長時間的存取內存操作，還不如簡單的忽略那些太小的內存塊而只做一些浮動指針的操作。（His observation was that the long-term saving in instructions by not having to ignore unusable small storage chunks far and away exceeded the additional cost of doing a few floating point operations on an allocation operation.）他是對的。
永遠不要認為所謂的“最優化”是建立在每一行代碼都高速且節省內存的基礎上的，事實上，高速且節省內存應該是在一個應用程序的整體水平上考慮的。在軟件的整體水平上，只使用最小內存的字符串分配策略可能是最糟糕的一種方法。
如果你認為優化是你在每一行代碼上做的那些努力的話，你應該想一想：在每一行代碼中做的優化很少能真正起作用。你可以看我的另一篇關於優化問題的文章《Your Worst Enemy for some thought-provoking ideas》。
記住，+= 運算符只是一種特例，如果你寫成下面這樣：
CString s = SomeCString1 + SomeCString2 + SomeCString3 + "," + SomeCString4;
則每一個 + 的應用會造成一個新的字符串被創建和一次復制操作。
總結
以上是使用 CString 的一些技巧。我每天寫程序的時候都會用到這些。CString 並不是一種很難使用的類，但是 MFC 沒有很明顯的指出這些特征，需要你自己去探索、去發現。
