通過閱讀本文你可以學習如何有效地使用 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; //編譯器報錯

// ... 填寫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;

則每一個 + 的應用會造成一個新的字串被建立和一次複製操作。