原著：Joseph M. Newcomer
翻譯：littleloach
原文出處：codeproject：CString Management
通過閱讀本文您能夠學習如何有效地使用 CString。
CString 是一種很有用的資料類型。他們很大程度上簡化了MFC中的許多操作，使得MFC在做字元串操作的時候友善了很多。不管怎樣，使用CString有很多特别的技巧，特别是對于純C背景下走出來的程式員來說有點難以學習。這篇文章就來讨論這些技巧。
使用CString能夠讓您對字元串的操作更加直截了當。這篇文章不是CString的完全手冊，但囊括了大部分常見基本問題。
這篇文章包括以下内容：
1. CString 對象的連接配接
2. 格式化字元串（包括 int 型轉化為 CString ）
3. CString 型轉化成 int 型
4. CString 型和 char* 類型的互相轉化
5. char* 轉化成 CString
6. CString 轉化成 char* 之一：使用LPCTSTR強制轉化
7. CString 轉化成 char* 之二：使用CString對象的GetBuffer方法
8. CString 轉化成 char* 之三: 和控件的接口
9. CString 型轉化成 BSTR 型；
10. BSTR 型轉化成 CString 型；
11. VARIANT 型轉化成 CString 型；
12. 載入字元串表資源；
13. CString 和臨時對象；
14. CString 的效率；
15. 總結
下面我分别讨論。
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)
{
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("");
}
}
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;
則每一個 + 的應用會造成一個新的字元串被建立和一次複制操作。
![處理PCX檔案[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)