MFC中的CString類使用方法指南
原文出處：codeproject：CString Management
【禾路：這是一篇比較老的資料了，但是對於MFC的程序設計很有幫助。我們在MFC中使用字符串的相關操作，首先想到的就應該啊是CString，而不是char*或者string。那么關於CString 的相關內容，在這篇文章中就很好的解釋。
我解決了一個具體的問題
}
這樣，可以將我圖像處理獲得的結果直接打印出來，效果很好。】
CString 是一種很有用的MFC數據類型。它們很大程度上簡化了MFC中的許多操作，使得MFC在做字符串操作的時候方便了很多。不管怎樣，使用CString有很多特殊的技巧，特別是對於純C背景下走出來的程序員來說有點難以學習。這篇文章就來討論這些技巧。
使用CString可以讓你對字符串的操作更加直截了當。這篇文章不是CString的完全手冊，但囊括了大部分常見基本問題。
這篇文章包括以下內容：
- 格 式化字符串（包括 int 型轉化為 CString ）
- CString 型轉化成 int 型
- CString 型和 char* 類型的相互轉化
- CString 型轉化成 BSTR 型；
- BSTR 型轉化成 CString 型；
- VARIANT 型轉化成 CString 型；
- 載 入字符串表資源；
- 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
++)
// 掃描表格尋找匹配項。
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 對象做任何操作。