1. CString 对象的连接

2. 格式化字符串（包括 int 型转化为 CString ）
3. CString 型转化成 int 型
4. CString 型和 char* 类型的相互转化
   
   char* 转化成 CString
   CString 转化成 char* 之一：使用LPCTSTR强制转化
   CString 转化成 char* 之二：使用CString对象的GetBuffer方法
   CString 转化成 char* 之三: 和控件的接口
5. CString 型转化成 BSTR 型；
6. BSTR 型转化成 CString 型；
7. VARIANT 型转化成 CString 型；
8. 载入字符串表资源；
9. CString 和临时对象；
10. CString 的效率；
11. 总结

下面我分别讨论。

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

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); // RIGHTWriteFile(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 onlyCString s = _T("This is a test"); // Unicode-awareCString s("This is a test"); // 8-bit onlyCString s(_T("This is a test")); // Unicode-awareCString 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(); // 现在应该 OKint 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 tvitvi.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 = ... ; // whateverBSTR 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 = ...; // whateverCString 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;}

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

你还可以根据 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 */}

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 文件中：

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

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

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 没有很明显的指出这些特征，需要你自己去探索、去发现。

C++字符串完全指引之一 —— Win32 字符编码


原著：Michael Dunn

翻译：Chengjie Sun

原文出处：CodeProject：The Complete Guide to C++ Strings, Part I

引言

　　毫无疑问，我们都看到过像 TCHAR, std::string, BSTR 等各种各样的字符串类型，还有那些以 _tcs 开头的奇怪的宏。你也许正在盯着显示器发愁。本指引将总结引进各种字符类型的目的，展示一些简单的用法，并告诉您在必要时，如何实现各种字符串类型之间的转换。
　　在第一部分，我们将介绍3种字符编码类型。了解各种编码模式的工作方式是很重要的事情。即使你已经知道一个字符串是一个字符数组，你也应该阅读本部分。一旦你了解了这些，你将对各种字符串类型之间的关系有一个清楚地了解。
　　在第二部分，我们将单独讲述string类，怎样使用它及实现他们相互之间的转换。

字符基础 -- ASCII, DBCS, Unicode

　　所有的 string 类都是以C-style字符串为基础的。C-style 字符串是字符数组。所以我们先介绍字符类型。这里有3种编码模式对应3种字符类型。第一种编码类型是单子节字符集（single-byte character set or SBCS）。在这种编码模式下，所有的字符都只用一个字节表示。ASCII是SBCS。一个字节表示的0用来标志SBCS字符串的结束。
　　第二种编码模式是多字节字符集（multi-byte character set or MBCS）。一个MBCS编码包含一些一个字节长的字符，而另一些字符大于一个字节的长度。用在Windows里的MBCS包含两种字符类型，单字节字符（single-byte characters）和双字节字符（double-byte characters）。由于Windows里使用的多字节字符绝大部分是两个字节长，所以MBCS常被用DBCS代替。
　　在DBCS编码模式中，一些特定的值被保留用来表明他们是双字节字符的一部分。例如，在Shift-JIS编码中（一个常用的日文编码模式），0x81-0x9f之间和 0xe0-oxfc之间的值表示"这是一个双字节字符，下一个子节是这个字符的一部分。"这样的值被称作"leading bytes",他们都大于0x7f。跟随在一个leading byte子节后面的字节被称作"trail byte"。在DBCS中，trail byte可以是任意非0值。像SBCS一样，DBCS字符串的结束标志也是一个单字节表示的0。
　　第三种编码模式是Unicode。Unicode是一种所有的字符都使用两个字节编码的编码模式。Unicode字符有时也被称作宽字符，因为它比单子节字符宽（使用了更多的存储空间）。注意，Unicode不能被看作MBCS。MBCS的独特之处在于它的字符使用不同长度的字节编码。Unicode字符串使用两个字节表示的0作为它的结束标志。
　　单字节字符包含拉丁文字母表，accented characters及ASCII标准和DOS操作系统定义的图形字符。双字节字符被用来表示东亚及中东的语言。Unicode被用在COM及Windows NT操作系统内部。
　　你一定已经很熟悉单字节字符。当你使用char时，你处理的是单字节字符。双字节字符也用char类型来进行操作（这是我们将会看到的关于双子节字符的很多奇怪的地方之一）。Unicode字符用wchar_t来表示。Unicode字符和字符串常量用前缀L来表示。例如：

wchar_t wch = L''1''; // 2 bytes, 0x0031
            wchar_t* wsz = L"Hello"; // 12 bytes, 6 wide characters

字符在内存中是怎样存储的

　　单字节字符串：每个字符占一个字节按顺序依次存储，最后以单字节表示的0结束。例如。"Bob"的存贮形式如下：

Unicode的存储形式，L"Bob"

使用两个字节表示的0来做结束标志。

　　一眼看上去，DBCS 字符串很像 SBCS 字符串，但是我们一会儿将看到 DBCS 字符串的微妙之处，它使得使用字符串操作函数和永字符指针遍历一个字符串时会产生预料之外的结果。字符串" " ("nihongo")在内存中的存储形式如下（LB和TB分别用来表示 leading byte 和 trail byte）

93 FA	96 7B	8C EA	00
LB TB	LB TB	LB TB	EOS
			EOS

值得注意的是，"ni"的值不能被解释成WORD型值0xfa93，而应该看作两个值93和fa以这种顺序被作为"ni"的编码。

使用字符串处理函数

　　我们都已经见过C语言中的字符串函数，strcpy(), sprintf(), atoll()等。这些字符串只应该用来处理单字节字符字符串。标准库也提供了仅适用于Unicode类型字符串的函数，比如wcscpy(), swprintf(), wtol()等。
　　微软还在它的CRT(C runtime library)中增加了操作DBCS字符串的版本。Str***()函数都有对应名字的DBCS版本_mbs***()。如果你料到可能会遇到DBCS字符串（如果你的软件会被安装在使用DBCS编码的国家，如中国，日本等，你就可能会），你应该使用_mbs***()函数，因为他们也可以处理SBCS字符串。（一个DBCS字符串也可能含有单字节字符，这就是为什么_mbs***()函数也能处理SBCS字符串的原因）
　　让我们来看一个典型的字符串来阐明为什么需要不同版本的字符串处理函数。我们还是使用前面的Unicode字符串 L"Bob"：

　　因为x86CPU是little-endian，值0x0042在内存中的存储形式是42 00。你能看出如果这个字符串被传给strlen()函数会出现什么问题吗？它将先看到第一个字节42，然后是00，而00是字符串结束的标志，于是strlen()将会返回1。如果把"Bob"传给wcslen()，将会得出更坏的结果。wcslen()将会先看到0x6f42，然后是0x0062，然后一直读到你的缓冲区的末尾，直到发现00 00结束标志或者引起了GPF。
　　到目前为止，我们已经讨论了str***()和wcs***()的用法及它们之间的区别。Str***()和_mbs**()之间的有区别区别呢？明白他们之间的区别，对于采用正确的方法来遍历DBCS字符串是很重要的。下面，我们将先介绍字符串的遍历，然后回到str***()与_mbs***()之间的区别这个问题上来。

正确的遍历和索引字符串

　　因为我们中大多数人都是用着SBCS字符串成长的，所以我们在遍历字符串时，常常使用指针的++-和-操作。我们也使用数组下标的表示形式来操作字符串中的字符。这两种方式是用于SBCS和Unicode字符串，因为它们中的字符有着相同的宽度，编译器能正确的返回我们需要的字符。
　　然而，当碰到DBCS字符串时，我们必须抛弃这些习惯。这里有使用指针遍历DBCS字符串时的两条规则。违背了这两条规则，你的程序就会存在DBCS有关的bugs。

　　我们先来阐述规则2，因为找到一个违背它的真实的实例代码是很容易的。假设你有一个程序在你自己的目录里保存了一个设置文件，你把安装目录保存在注册表中。在运行时，你从注册表中读取安装目录，然后合成配置文件名，接着读取该文件。假设，你的安装目录是C:\Program Files\MyCoolApp，那么你合成的文件名应该是C:\Program Files\MyCoolApp\config.bin。当你进行测试时，你发现程序运行正常。
　　现在，想象你合成文件名的代码可能是这样的：

bool GetConfigFileName ( char* pszName, size_t nBuffSize )
            {
            char szConfigFilename[MAX_PATH];
            // Read install dir from registry... we''ll assume it succeeds.
            // Add on a backslash if it wasn''t present in the registry value.
            // First, get a pointer to the terminating zero.
            char* pLastChar = strchr ( szConfigFilename, ''\0'' );
            // Now move it back one character.
            pLastChar--;
            if ( *pLastChar != ''\\'' )
            strcat ( szConfigFilename, "\\" );
            // Add on the name of the config file.
            strcat ( szConfigFilename, "config.bin" );
            // If the caller''s buffer is big enough, return the filename.
            if ( strlen ( szConfigFilename ) >= nBuffSize )
            return false;
            else
            {
            strcpy ( pszName, szConfigFilename );
            return true;
            }
            }      

43	3A	5C	83 88	83 45	83 52	83 5C	00
			LB TB	LB TB	LB TB	LB TB
C	:	\					EOS

　　当使用 GetConfigFileName() 检查尾部的''\\''时，它寻找安装目录名中最后的非0字节，看它是等于''\\''的，所以没有重新增加一个''\\''。结果是代码返回了错误的文件名。
　　哪里出错了呢？看看上面两个被用蓝色高量显示的字节。斜杠''\\''的值是0x5c。'' ''的值是83 5c。上面的代码错误的读取了一个 trail byte，把它当作了一个字符。
　　正确的后向遍历方法是使用能够识别DBCS字符的函数，使指针移动正确的字节数。下面是正确的代码。（指针移动的地方用红色标明）

bool FixedGetConfigFileName ( char* pszName, size_t nBuffSize )
            {
            char szConfigFilename[MAX_PATH];
            // Read install dir from registry... we''ll assume it succeeds.
            // Add on a backslash if it wasn''t present in the registry value.
            // First, get a pointer to the terminating zero.
            char* pLastChar = _mbschr ( szConfigFilename, ''\0'' );
            // Now move it back one double-byte character.
              pLastChar = CharPrev ( szConfigFilename, pLastChar );
            if ( *pLastChar != ''\\'' )
            _mbscat ( szConfigFilename, "\\" );
            // Add on the name of the config file.
            _mbscat ( szConfigFilename, "config.bin" );
            // If the caller''s buffer is big enough, return the filename.
            if ( _mbslen ( szInstallDir ) >= nBuffSize )
            return false;
            else
            {
            _mbscpy ( pszName, szConfigFilename );
            return true;
            }
            }
            

2a. 永远不要使用减法去得到一个字符串的索引。

违背这条规则的代码和违背规则2的代码很相似。例如，

char* pLastChar = &szConfigFilename [strlen(szConfigFilename) - 1];

这和向后移动一个指针是同样的效果。

回到关于str***()和_mbs***()的区别

　　现在，我们应该很清楚为什么_mbs***()函数是必需的。Str***()函数根本不考虑DBCS字符，而_mbs***()考虑。如果，你调用strrchr("C:\\ ", ''\\'')，返回结果可能是错误的，然而_mbsrchr()将会认出最后的双字节字符，返回一个指向真的''\\''的指针。
　　关于字符串函数的最后一点：str***()和_mbs***()函数认为字符串的长度都是以char来计算的。所以，如果一个字符串包含3个双字节字符，_mbslen()将会返回6。Unicode函数返回的长度是按wchar_t来计算的。例如，wcslen(L"Bob")返回3。

Win32 API中的MBCS和Unicode

两组 APIs：
　　尽管你也许从来没有注意过，Win32中的每个与字符串相关的API和message都有两个版本。一个版本接受MBCS字符串，另一个接受Unicode字符串。例如，根本没有SetWindowText()这个API，相反，有SetWindowTextA()和SetWindowTextW()。后缀A表明这是MBCS函数，后缀W表示这是Unicode版本的函数。
　　当你 build 一个 Windows 程序，你可以选择是用 MBCS 或者 Unicode APIs。如果，你曾经用过VC向导并且没有改过预处理的设置，那表明你用的是MBCS版本。那么，既然没有 SetWindowText() API，我们为什么可以使用它呢？winuser.h头文件包含了一些宏，例如：

BOOL WINAPI SetWindowTextA ( HWND hWnd, LPCSTR lpString );
            BOOL WINAPI SetWindowTextW ( HWND hWnd, LPCWSTR lpString );
            #ifdef UNICODE
            #define SetWindowText  SetWindowTextW
            #else
            #define SetWindowText  SetWindowTextA
            #endif      

#define SetWindowText SetWindowTextA

　　这个宏定义把所有对SetWindowText的调用都转换成真正的API函数SetWindowTextA。（当然，你可以直接调用SetWindowTextA() 或者 SetWindowTextW()，虽然你不必那么做。）
　　所以，如果你想把默认使用的API函数变成Unicode版的，你可以在预处理器设置中，把_MBCS从预定义的宏列表中删除，然后添加UNICODE和_UNICODE。(你需要两个都定义，因为不同的头文件可能使用不同的宏。) 然而，如果你用char来定义你的字符串，你将会陷入一个尴尬的境地。考虑下面的代码：

HWND hwnd = GetSomeWindowHandle();
            char szNewText[] = "we love Bob!";
            SetWindowText ( hwnd, szNewText );

在预处理器把SetWindowText用SetWindowTextW来替换后，代码变成：

HWND hwnd = GetSomeWindowHandle();
            char szNewText[] = "we love Bob!";
            SetWindowTextW ( hwnd, szNewText );

　　看到问题了吗？我们把单字节字符串传给了一个以Unicode字符串做参数的函数。解决这个问题的第一个方案是使用 #ifdef 来包含字符串变量的定义：

HWND hwnd = GetSomeWindowHandle();
            #ifdef UNICODE
            wchar_t szNewText[] = L"we love Bob!";
            #else
            char szNewText[] = "we love Bob!";
            #endif
            SetWindowText ( hwnd, szNewText );

你可能已经感受到了这样做将会使你多么的头疼。完美的解决方案是使用TCHAR.

使用TCHAR

　　TCHAR是一种字符串类型，它让你在以MBCS和UNNICODE来build程序时可以使用同样的代码，不需要使用繁琐的宏定义来包含你的代码。TCHAR的定义如下：

#ifdef UNICODE
            typedef wchar_t TCHAR;
            #else
            typedef char TCHAR;
            #endif

所以用MBCS来build时，TCHAR是char，使用UNICODE时，TCHAR是wchar_t。还有一个宏来处理定义Unicode字符串常量时所需的L前缀。

#ifdef UNICODE
            #define _T(x) L##x
            #else
            #define _T(x) x
            #endif

　　##是一个预处理操作符，它可以把两个参数连在一起。如果你的代码中需要字符串常量，在它前面加上_T宏。如果你使用Unicode来build，它会在字符串常量前加上L前缀。

TCHAR szNewText[] = _T("we love Bob!");

　　像是用宏来隐藏SetWindowTextA/W的细节一样，还有很多可以供你使用的宏来实现str***()和_mbs***()等字符串函数。例如，你可以使用_tcsrchr宏来替换strrchr()、_mbsrchr()和wcsrchr()。_tcsrchr根据你预定义的宏是_MBCS还是UNICODE来扩展成正确的函数，就像SetWindowText所作的一样。
　　不仅str***()函数有TCHAR宏。其他的函数如， _stprintf（代替sprinft()和swprintf()）,_tfopen（代替fopen()和_wfopen()）。 MSDN中"Generic-Text Routine Mappings."标题下有完整的宏列表。

字符串和TCHAR typedefs

　　由于Win32 API文档的函数列表使用函数的常用名字（例如，"SetWindowText"），所有的字符串都是用TCHAR来定义的。（除了XP中引入的只适用于Unicode的API）。下面列出一些常用的typedefs，你可以在msdn中看到他们。

何时使用 TCHAR 和 Unicode

　　到现在，你可能会问，我们为什么要使用Unicode。我已经用了很多年的char。下列3种情况下，使用Unicode将会使你受益：

　　Windows 9x 中大多数的 API 没有实现 Unicode 版本。所以，如果你的程序要在windows 9x中运行，你必须使用MBCS APIs。然而，由于NT系统内部都使用Unicode，所以使用Unicode APIs将会加快你的程序的运行速度。每次，你传递一个字符串调用MBCS API，操作系统会把这个字符串转换成Unicode字符串，然后调用对应的Unicode API。如果一个字符串被返回，操作系统还要把它转变回去。尽管这个转换过程被高度优化了，但它对速度造成的损失是无法避免的。
　　只要你使用Unicode API，NT系统允许使用非常长的文件名（突破了MAX_PATH的限制，MAX_PATH=260）。使用Unicode API的另一个优点是你的程序会自动处理用户输入的各种语言。所以一个用户可以输入英文，中文或者日文，而你不需要额外编写代码去处理它们。
　　最后，随着windows 9x产品的淡出，微软似乎正在抛弃MBCS APIs。例如，包含两个字符串参数的SetWindowTheme() API只有Unicode版本的。使用Unicode来build你的程序将会简化字符串的处理，你不必在MBCS和Unicdoe之间相互转换。
　　即使你现在不使用Unicode来build你的程序，你也应该使用TCHAR及其相关的宏。这样做不仅可以的代码可以很好地处理DBCS，而且如果将来你想用Unicode来build你的程序，你只需要改变一下预处理器中的设置就可以实现了。

【版   本】

1.0.0

【操作系统】

Windows Mobile 5.0

【作   者】

谢红伟·chrys ·chrys@163.com ·http://www.howa.com.cn

【开发日期】

2007-12-11 01:23:56

最近编写一个医疗项目的程序，需要用 Windows Mobile 来做通信处理，需要将手机端的数据通过GPRS传送至公网上的一个服务器上。数据传输我采用的是socket，用数据线+ActiveSync调试通过，数据传输正常，在准备将软件提交给质检部门的时候，用真正的GPRS来做通信测试时，问题出来了，连接始终建立不了，但用手机的IE浏览器却能正常打开网页，而且奇怪的是只要用IE浏览器成功访问过一次网页，我的 socket 就能正常进行数据通信，看来传说中的GPRS常连接被我误解了。

手机开通GPRS以后，我们的socket 程序还不能直接建立网络连接，需要用连接管理器来获取当前可用连接，并自动选择一个最佳的连接途径，然后启用这个连接，在连接启动成功以后再用socket 进行网络连接方可正常进行。大概GPRS拨号和连接过程就是在这里自动进行的吧。源代码中封装了一个连接管理的类和测试代码，可以清楚地看到Windows Mobile 在socket 编程之前到底需要做什么样的操作。

首先需要枚举当前可用的连接

void CConnectManager::EnumNetIdentifier ( OUT CStringArray &StrAry )

{

       CONNMGR_DESTINATION_INFO networkDestInfo = {0};

       // 得到网络列表

       for ( DWORD dwEnumIndex=0; ; dwEnumIndex++ )

       {

              memset ( &networkDestInfo, 0, sizeof(CONNMGR_DESTINATION_INFO) );

              if ( ConnMgrEnumDestinations ( dwEnumIndex, &networkDestInfo ) == E_FAIL )

              {

                     break;

              }

              StrAry.Add ( networkDestInfo.szDescription );

       }

}

接下来找到“Internet”这个连接，可用远程URL映射的方式来完成，这样可以让系统自动选取一个最好的连接。

int CConnectManager::MapURLAndGUID ( LPCTSTR lpszURL, OUT GUID &guidNetworkObject, OUT CString *pcsDesc/*=NULL*/ )

{

       if ( !lpszURL || lstrlen(lpszURL) < 1 )

              return FALSE;

       memset ( &guidNetworkObject, 0, sizeof(GUID) );

       int nIndex = 0;

       HRESULT hResult = ConnMgrMapURL ( lpszURL, &guidNetworkObject, (DWORD*)&nIndex );

       if ( FAILED(hResult) )

       {

              nIndex = -1;

              DWORD dwLastError = GetLastError ();

              AfxMessageBox ( _T("Could not map a request to a network identifier") );

       }

       else

       {

              if ( pcsDesc )

              {

                     CONNMGR_DESTINATION_INFO DestInfo = {0};

                     if ( SUCCEEDED(ConnMgrEnumDestinations(nIndex, &DestInfo)) )

                     {

                            *pcsDesc = DestInfo.szDescription;

                     }

              }

       }

       return nIndex;

}

以下代码是用来启用指定编号的连接

BOOL CConnectManager::EstablishConnection ( DWORD dwIndex )

{

       ReleaseConnection ();

       // 得到正确的连接信息

       CONNMGR_DESTINATION_INFO DestInfo = {0};

       HRESULT hResult = ConnMgrEnumDestinations(dwIndex, &DestInfo);

       BOOL bRet = FALSE;

       if(SUCCEEDED(hResult))

       {

              // 初始化连接结构

              CONNMGR_CONNECTIONINFO ConnInfo;

              ZeroMemory(&ConnInfo, sizeof(ConnInfo));

              ConnInfo.cbSize = sizeof(ConnInfo);

              ConnInfo.dwParams = CONNMGR_PARAM_GUIDDESTNET;

              ConnInfo.dwFlags = CONNMGR_FLAG_PROXY_HTTP | CONNMGR_FLAG_PROXY_WAP | CONNMGR_FLAG_PROXY_SOCKS4 | CONNMGR_FLAG_PROXY_SOCKS5;

              ConnInfo.dwPriority = CONNMGR_PRIORITY_USERINTERACTIVE;

              ConnInfo.guidDestNet = DestInfo.guid;

              ConnInfo.bExclusive     = FALSE;

              ConnInfo.bDisabled = FALSE;

              DWORD dwStatus = 0;

              hResult = ConnMgrEstablishConnectionSync(&ConnInfo, &m_hConnection, 10*1000, &dwStatus );

              if(FAILED(hResult))

              {

                     m_hConnection = NULL;

              }

              else bRet = TRUE;

       }

       return bRet;

}

为了确保连接是否真正可用，需要检测连接状态，在规定的时间内如果未取得“连接成功”的状态，则认为连接未能正常启用，可能需要配置手机的连接管理器界面

BOOL CConnectManager::WaitForConnected ( int nTimeoutSec, DWORD *pdwStatus/*=NULL*/ )

{

       DWORD dwStartTime = GetTickCount ();

       BOOL bRet = FALSE;

       while ( GetTickCount ()-dwStartTime < (DWORD)nTimeoutSec * 1000 )

       {

              if ( m_hConnection )

              {

                     DWORD dwStatus = 0;

                     HRESULT hr = ConnMgrConnectionStatus ( m_hConnection, &dwStatus );

                     if ( pdwStatus ) *pdwStatus = dwStatus;

                     if ( SUCCEEDED(hr) )

                     {

                            if ( dwStatus == CONNMGR_STATUS_CONNECTED )

                            {

                                   bRet = TRUE;

                                   break;

                            }

                     }

              }

              Sleep ( 100 );

       }

       return bRet;

}

至此，我们的连接启用工作已经做完了，我们可以用我们熟悉的 socket 来编写网络通信程序了。下面是一个测试 socket 测试网络连接是否能正常建立的例子：

SetWaitCursor ();

CSocket sock;

sock.Create ();

if ( sock.Connect ( _T("www.baidu.com"), 80 ) )

{

       RestoreCursor ();

       AfxMessageBox ( _T("Connect to www.baidu.com successfully"), MB_ICONINFORMATION );

}

else

{

       RestoreCursor ();

       AfxMessageBox ( _T("Connect to www.baidu.com failed") );

}

GPRSDemo.exe 的使用

程序启动以后出现如下界面：

连接可用性 – 检测连接管理器是否可用

映射URL – 是让系统自动寻找一个最好的连接

枚举网络标识符 – 将当前系统中所有可用的连接都会被枚举出来

连接网络 – 将枚举出来的连接选中的那个连接进行连接启用操作。

连接状态 – 表示可以获取到当前连接的状态；

连接到公网测试 – 利用 www.baidu.com 来测试连接是否已经正常启动。

操作步骤：

可以直接按“枚举网络标识符”，程序将所有当前在用的网络枚举出来并添加到 ListBox 控件中；

连接网络。选择一个连接（例如：Internet），按“连接网络”按钮，当提示 Connection net successfully 表示连接已经正常启用了。

按“连接到公网测试”按钮，软件自动和 www.baidu.com 进行连接测试。

源代码下载地址：http://www.pudn.com/downloads94/sourcecode/embed/detail373151.html

原型：DWORD WaitForMultipleObjects(

 DWORD nCount,

 const HANDLE* lpHandles,

 BOOL bWaitAll,

 DWORD dwMilliseconds

);

当WaitForMultipleObjects等到多个内核对象的时候，如果它的bWaitAll 参数设置为false。其返回值减去WAIT_OBJECT_0 就是参数lpHandles数组的序号。如果同时有多个内核对象被出发，这个函数返回的只是其中序号最小的那个。

问题就在这里，我们如何可以获取所有被同时触发的内核对象。举个例子：我们需要在一个线程中处理从完成端口、数据库、和可等待定时器来的数据。一个典型的实现方法就是：用WaitForMultipleObjects等待所有的这些事件。如果完成端口，数据库发过来的数据量非常大，可等待定时器时间也只有几十毫秒。那么这些事件同时触发的几率可以说非常大，我们不希望丢弃任何一个被触发的事件。那么如何能高效地实现这一处理呢？

MSDN中有一句非常重要的描述，它可以说是WaitForMultipleObjects用法的精髓：The function modifies the state of some types of synchronization objects. Modification occurs only for the object or objects whose signaled state caused the function to return. For example, the count of a semaphore object is decreased by one. When bWaitAll is FALSE, and multiple objects are in the signaled state, the function chooses one of the objects to satisfy the wait; the states of the objects not selected are unaffected.

多个内核对象被触发时，WaitForMultipleObjects选择其中序号最小的返回。而WaitForMultipleObjects它只会改变使它返回的那个内核对象的状态。

这儿又会产生一个问题，如果序号最小的那个对象频繁被触发，那么序号比它大的内核对象将得不到被处理的机会。

为了解决这一问题，可以采用双WaitForMultipleObjects检测机制来实现。见下面的例子：

DWORD WINAPI ThreadProc(LPVOID lpParameter) {     DWORD dwRet = 0;     int   nIndex = 0;     while(1)     {         dwRet = WaitForMultipleObjects(nCount,pHandles,false,INFINITE);           switch(dwRet)         {         case WAIT_TIMEOUT:             break;         case WAIT_FAILED:             return 1;         default:             {                 nIndex = dwRet - WAIT_OBJECT_0;                   ProcessHanlde(nIndex++);                 //同时检测其他的事件                 while(nIndex < nCount)                 {                     dwRet = WaitForMultipleObjects(nCount - nIndex,&pHandles[nIndex],false,0);                       switch(dwRet)                     {                     case WAIT_TIMEOUT:                         nIndex = nCount; //退出检测,因为没有被触发的对象了.                         break;                     case WAIT_FAILED:                         return 1;                     default:                         {                             nIndex = dwRet - WAIT_OBJECT_0;                             ProcessHanlde(nIndex++);                         }                         break                     }                 }             }             break;         }     }     return 0; }

If you have ever dug into the MSDN for WinInet API, you noticed that it can be used asynchronously and that it is the recommended way to use it.

If then you decide to use it, you won’t find any explanation of how to use it asynchronously. And no samples are available anywhere on Internet. After a long research and lots of testing, I finally managed to reconstruct a big part of the (voluntary?) missing documentation.

Why asynchronous is better? Because it can handle timeouts correctly. Just what’s missing in WinInet under IE5.5.

If you try to use TerminateThread or CloseHandle functions to handle timeouts (these methods are given in MSDN articles), you’ll fall into unrecoverable leaks of all kinds.

This has been tested successfully with: IE4.01SP3, IE5.0, IE5.01, IE5.5SP1 under WinNT4 on mono and multiprocessor machines, under a stressed environment (15 concurrent instances running non-stop for 12 hours on multi-proc NT server machines).

Theory

To use WinInet functions in full asynchronous mode, you must do things in the right order:

1. Use INTERNET_FLAG_ASYNC to open the session
2. Set a status callback using InternetSetStatusCallback
3. Open the connection using InternetOpenUrl
4. If InternetOpenUrl returned NULL and GetLastError is ERROR_IO_PENDING:
   • wait for the INTERNET_STATUS_HANDLE_CREATED notification in the callback, and save the connection Handle.
   • wait for the INTERNET_STATUS_REQUEST_COMPLETE notification in the callback before going further.
5. Extract the content-length from the header and set up an INTERNET_BUFFERS structure:
   • dwStructSize = sizeof(INTERNET_BUFFERS)
   • lpvBuffer = your allocated buffer
   • dwBufferLength = its length
6. Use InternetReadFileEx with the IRF_ASYNC flag to read the remaining data asynchronously. Don’t use InternetReadFile since it is a synchronous function.
7. If InternetReadFileEx returned False and GetLastError is ERROR_IO_PENDING: wait for the INTERNET_STATUS_REQUEST_COMPLETE notification in the callback before going further.

   Warning: INTERNET_BUFFERS members are modified asynchronously (only the dwBufferLength member and the content of the buffer).

8. If the dwBufferLength member is not 0, move the lpvBuffer pointer from this amount and subtract this amount from the buffer length so dwBufferLength reflects the remaining size lpvBuffer points to, then loop to 6.
9. Close the connection handle with InternetCloseHandle and wait for INTERNET_STATUS_HANDLE_CLOSING and the facultative INTERNET_STATUS_REQUEST_COMPLETE notification (sent only if an error occurs – like a sudden closed connection -, you must test the cases).

At this state, you can either begin a new connection process or close the session handle. But before closing it, you should un-register the callback function.

Detail

After the theory, let’s look at some code for some of the points:

1&2: Create the connection using INTERNET_FLAG_ASYNC and setup the callback func:

m_Session = InternetOpen(AGENT_NAME, INTERNET_OPEN_TYPE_PRECONFIG,
NULL, NULL, INTERNET_FLAG_ASYNC);
InternetSetStatusCallback( m_Session,
(INTERNET_STATUS_CALLBACK)InternetCallbackFunc );

3&4: Open the connection using InternetOpenUrl and wait for INTERNET_STATUS_REQUEST_COMPLETE

Use the lParam to send a session identifier to your callback. I always use the this pointer of my class for it. I assume you know how to handle callbacks.

InternetOpenUrl( m_Session, uurl, NULL, 0,
INTERNET_FLAG_RELOAD | INTERNET_FLAG_PRAGMA_NOCACHE |
INTERNET_FLAG_NO_CACHE_WRITE, (LPARAM)this );

The callback will receive a lots of messages then. Here are their orders along with the dwInternetStatus value:

[openUrl] InternetStatus: 60 INTERNET_STATUS_HANDLE_CREATED
**At this point you can save the HINTERNET handle using code like this in your callback:
INTERNET_ASYNC_RESULT* res = (INTERNET_ASYNC_RESULT*)lpvStatusInformation;
m_hHttpFile = (HINTERNET)(res->dwResult);
[openUrl] InternetStatus: 10
[openUrl] InternetStatus: 11
[openUrl] InternetStatus: 20
[openUrl] InternetStatus: 21
[openUrl] InternetStatus: 30
[openUrl] InternetStatus: 31
[openUrl] InternetStatus: 40
[openUrl] InternetStatus: 41
[openUrl] InternetStatus: 100 INTERNET_STATUS_REQUEST_COMPLETE

5: Extract the content-length and set up the INTERNET_BUFFERS structure

Once you have the handle, try to call HttpQueryInfo with HTTP_QUERY_CONTENT_LENGTH to get the size of the data to retrieve. This function can fail if the content-length field is not in the HTTP header.

Set up the INTERNET_BUFFERS structure.

INTERNET_BUFFERS ib = { sizeof(INTERNET_BUFFERS) };
ib.lpvBuffer = your allocated buffer
ib.dwBufferLength = its length

The dwBufferTotal is provided for your own use and is never modified by WinInet (as far as I know). I use it to store the total size of the received data.

6&7&8 Read the remaining data in a loop

Use InternetReadFileEx with the IRF_ASYNC flag to read the remaining data asynchronously. Don’t use InternetReadFile since it is a synchronous function. You must loop on InternetReadFileEx while the ib.dwBufferLength is not 0. Before each iteration you must adjust the lpvBuffer pointer and reset the dwBufferLength members of ib: add the received length to the pointer and set dwBufferLength to your remaining buffer size.

//Start the pump
BOOL bOk = InternetReadFileEx( m_hHttpFile, &ib, IRF_ASYNC, (LPARAM)this );
if(!bOk && GetLastError()==ERROR_IO_PENDING)
wait...
//Pump
while( bOk && ib.dwBufferLength!=0 )
{
(adjust ib values)
bOk = InternetReadFileEx( m_hHttpFile, &ib, IRF_ASYNC, (LPARAM)this );
if(!bOk && GetLastError()==ERROR_IO_PENDING)
wait...
}

Your callback should receive these notifications (maybe more than once):

[connect] InternetStatus: 40 (receiving response)
[connect] InternetStatus: 41 (response received)
[connect] InternetStatus: 50
[connect] InternetStatus: 51
and maybe
[connect] InternetStatus: 100 INTERNET_STATUS_REQUEST_COMPLETE

The last is received only if GetLastError() returned ERROR_IO_PENDING. If you stored the total data size (in bytes) in the dwBufferTotal member, use it to set the final “0” in your string buffer (if it’s a string).

buf[ib.dwBufferTotal] = 0;

9 Close the connection handle

InternetCloseHandle( m_httpFile );

The callback will receive this notification when the handle is closed:

[connect] InternetStatus: 70 INTERNET_STATUS_HANDLE_CLOSING

In most error cases, the connection is closed unexpectedly. If it happens you’ll receive a 70 followed by a 100 (INTERNET_STATUS_REQUEST_COMPLETE). This can happen anywhere during the process.

10 Before closing the m_Session handle

You must deregister the callback:

InternetSetStatusCallback( m_Session, NULL );

This should help those who tried to go through asynchronous mode in WinInet! Sorry, there are no attached files but you should be able to use the functions and create nice classes now. If you liked this article please add an entry in my guestbook and buy me a license of my shareware.

Bibliography

• Microsoft website
• Q176420: BUG: InternetSetOption Does Not Set Timeout Values
• Q176176: FIX: InternetOpenUrl Does Not Work When Called Asynchronously
• Q238425: INFO: WinInet Not Supported for Use in Services
• Q190542: INFO: Using WinInet APIs in a System Service to access SSL sites
• Microsft Newsgroup

About the Author

Benjamin Mayrargue

Location: United States

BOOL SortItems( PFNLVCOMPARE pfnCompare, DWORD dwData );

dwData: 指定的是列表对象.

回调函数的原型如下:
MyCompareProc(LPARAM lParam1, LPARAM lParam2, LPARAM lParamSort)
参数lParam1和lParam2 其实是两个列表Item的索引值, 排序实际上就是对这个值进行比较.
lParamSort包含了指向TreeCtrl控件的指针,可强制转换过来.

这里需要注意的问题是,在调用SortItems()方法之前,必须调用SetItemData( int nItem, DWORD dwData ) 方法来设置回调函数中使用到LPARAM lParam1, LPARAM lParam2
MSDN中对于SetItemData()函数的解释如下:
This function sets the 32-bit application-specific value associated with the item specified by nItem. This value is the lParam member of the LVITEM structure, as described in the Platform SDK.

所以不调用SetItemData方法,直接去调用SortItem方法就会出现排序无效的结果.

When you receive the error message that is described in the "Symptoms" section, continue with the Visual Studio Setup Wizard. Setup reports a failure.
To create a local account, which Visual Studio Analyzer will run as: 1. On the computer that is running Visual Studio Enterprise Edition 6.0, create a local user. For information about how to create a local user, see Windows 2000 Help. 
2. Run Distributed COM Configuration (dcomcnfg.exe).
3. On the Applications tab, click MSVSA Local Event Concentrator Class, and then click Properties.
4. On the Identity tab, set This User to match the user and password you created in step 1 of this procedure.

STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.