这里要提醒你的就是一定要注意那些在参数中需要真实字节数的API函数调用，如果你传递字符个数给它，它将不能正常工作。
如下：
TCHARdata[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），而后者相反。
看下面的例子：
CStringhex=_T（"FAB"）;
CStringdecimal=_T（"4011"）;
ASSERT（_tcstoul（hex,0,16）==_ttoi（decimal））;
4、CString型和char*类型的相互转化
这是初学者使用CString时最常见的问题。
有了C++的帮助，很多问题你不需要深入的去考虑它，直接拿来用就行了，但是如果你不能深入了解它的运行机制，又会有很多问题让你迷惑，特别是有些看起来没有问题的代码，却偏偏不能正常工作。
比如，你会奇怪为什么不能写向下面这样的代码呢：
CStringgraycat="Gray"+"Cat";
或者这样：
CStringgraycat（"Gray"+"Cat"）;
事实上，编译器将抱怨上面的这些尝试。
为什么呢？
因为针对CString和LPCTSTR数据类型的各种各样的组合，“+”运算符被定义成一个重载操作符。
而不是两个LPCTSTR数据类型，它是底层数据类型。
你不能对基本数据（如int、char或者char*）类型重载C++的运算符。
你可以象下面这样做：
CStringgraycat=CString（"Gray"）+CString（"Cat"）;
或者这样：
CStringgraycat=CString（"Gray"）+"Cat";
研究一番就会发现：
“+”总是使用在至少有一个CString对象和一个LPCSTR的场合。
注意，编写有Unicode意识的代码总是一件好事，比如：
CStringgraycat=CString（_T（"Gray"）+_T（"Cat"））;
这将使得你的代码可以直接移植。
char*转化为CString
现在你有一个char*类型的数据，或者说一个字符串。
怎么样创建CString对象呢？
这里有一些例子：
char*p="Thisisatest";
或者象下面这样更具有Unicode意识：
TCHAR*p=_T（"Thisisatest"）
或
LPTSTRp=_T（"Thisisatest"）;
你可以使用下面任意一种写法：
CStrings="Thisisatest";//8-bitonly
CStrings=_T（"Thisisatest"）;//Unicode-aware
CStrings（"Thisisatest"）;//8-bitonly
CStrings（_T（"Thisisatest"））;//Unicode-aware
CStrings=p;
CStrings（p）;
用这些方法可以轻松将常量字符串或指针转换成CString。
需要注意的是，字符的赋值总是被拷贝到CString对象中去的，所以你可以象下面这样操作：
TCHAR*p=_T（"Gray"）;
CStrings（p）;
p=_T（"Cat"）;
s+=p;
结果字符串肯定是“GrayCat”。
CString类还有几个其它的构造函数，但是这里我们不考虑它，如
果你有兴趣可以自己查看相关文档。
事实上，CString类的构造函数比我展示的要复杂，比如：
CStrings="Thisisatest";
这是很草率的编码，但是实际上它在Unicode环境下能编译通过。
它在运行时调用构造函数的MultiByteToWideChar操作将8位字符串转换成16位字符串。
不管怎样，如果char*指针是网络上传输的8位数据，这种转换是很有用的。
CString转化成char*之一：
强制类型转换为LPCTSTR；
这是一种略微硬性的转换，有关“正确”的做法，人们在认识上还存在许多混乱，正确的使用方法有很多，但错误的使用方法可能与正确的使用方法一样多。
我们首先要了解CString是一种很特殊的C++对象，它里面包含了三个值：
一个指向某个数据缓冲区的指针、一个是该缓冲中有效的字符记数以及一个缓冲区长度。
有效字符数的大小可以是从0到该缓冲最大长度值减1之间的任何数（因为字符串结尾有一个NULL字符）。
字符记数和缓冲区长度被巧妙隐藏。
除非你做一些特殊的操作，否则你不可能知道给CString对象分配的缓冲区的长度。
这样，即使你获得了该0缓冲的地址，你也无法更改其中的内容，不能截短字符串，也绝对没有办法加长它的内容，否则第一时间就会看到溢出。
LPCTSTR操作符（或者更明确地说就是TCHAR*操作符）在CString类中被重载了，该操作符的定义是返回缓冲区的地址，因此，如果你需要一个指向CString的字符串指针的话，可以这样做：
CStrings（"GrayCat"）;
LPCTSTRp=s;
它可以正确地运行。
这是由C语言的强制类型转化规则实现的。
当需要强制类型转化时，C++规测容许这种选择。
比如，你可以将（浮点数）定义为将某个复数（有一对浮点数）进行强制类型转换后只返回该复数的第一个浮点数（也就是其实部）。
可以象下面这样：
Complexc（1.2f,4.8f）;
floatrealpart=c;
如果（float）操作符定义正确的话，那么实部的的值应该是1.2。
这种强制转化适合所有这种情况，例如，任何带有LPCTSTR类型参数的函数都会强制执行这种转换。
于是，你可能有这样一个函数（也许在某个你买来的DLL中）：
BOOLDoSomethingCool（LPCTSTRs）;
你象下面这样调用它：
CStringfile（"c:
\\myfiles\\coolstuff"）
BOOLresult=DoSomethingCool（file）;
它能正确运行。
因为DoSomethingCool函数已经说明了需要一个LPCTSTR类型的参数，因此LPCTSTR被应用于该参数，在MFC中就是返回的串地址。
如果你要格式化字符串怎么办呢？
CStringgraycat（"GrayCat"）;
CStrings;
s.Format（"Mew!
Ilove%s",graycat）;
注意由于在可变参数列表中的值（在函数说明中是以“...”表示的）并没有隐含一个强制类型转换操作符。
你会得到什么结果呢？
一个令人惊讶的结果，我们得到的实际结果串是：
"Mew!
IloveGrayCat"。
因为MFC的设计者们在设计CString数据类型时非常小心，CString类型表达式求值后指向了字符串，所以这里看不到任何象Format或sprintf中的强制类型转换，你仍然可以得到正确的行为。
描述CString的附加数据实际上在CString名义地址之后。
有一件事情你是不能做的，那就是修改字符串。
比如，你可能会尝试用“,”代替“.”（不要做这样的，如果你在乎国际化问题，你应该使用十进制转换的NationalLanguageSupport特性，），下面是个简单的例子：
CStringv（"1.00"）;//货币金额，两位小数
LPCTSTRp=v;
p[lstrlen（p）-3]='','';
这时编译器会报错，因为你赋值了一个常量串。
如果你做如下尝试，编译器也会错：
strcat（p,"each"）;
因为strcat的第一个参数应该是LPTSTR类型的数据，而你却给了一个LPCTSTR。
不要试图钻这个错误消息的牛角尖，这只会使你自己陷入麻烦！
原因是缓冲有一个计数，它是不可存取的（它位于CString地址之下的一个隐藏区域），如果你改变这个串，缓冲中的字符计数不会反映所做的修改。
此外，如果字符串长度恰好是该字符串物理限制的长度（梢后还会讲到这个问题），那么扩展该字符串将改写缓冲以外的任何数据，那是你无权进行写操作的内存（不对吗？
），你会毁换坏不属于你的内存。
这是应用程序真正的死亡处方。
CString转化成char*之二：
使用CString对象的GetBuffer方法；
如果你需要修改CString中的内容，它有一个特殊的方法可以使用，那就是GetBuffer，它的作用是返回一个可写的缓冲指针。
如果你只是打算修改字符或者截短字符串，你完全可以这样做：
CStrings（_T（"File.ext"））;
LPTSTRp=s.GetBuffer（）;
LPTSTRdot=strchr（p,''.''）;//OK,shouldhaveuseds.Find...
if（p!
=NULL）
*p=_T（''\0''）;
s.ReleaseBuffer（）;
这是GetBuffer的第一种用法，也是最简单的一种，不用给它传递参数，它使用默认值0，意思是：
“给我这个字符串的指针，我保证不加长它”。
当你调用ReleaseBuffer时，字符串的实际长度会被重新计算，然后存入CString对象中。
必须强调一点，在GetBuffer和ReleaseBuffer之间这个范围，一定不能使用你要操作的这个缓冲的CString对象的任何方法。
因为ReleaseBuffer被调用之前，该CString对象的完整性得不到保障。
研究以下代码：
CStrings（...）;
LPTSTRp=s.GetBuffer（）;
//...这个指针p发生了很多事情
intn=s.GetLength（）;//很糟D!
!
!
!
!
有可能给出错误的答案!
!
!
s.TrimRight（）;//很糟!
!
!
!
!
不能保证能正常工作!
!
!
!
s.ReleaseBuffer（）;//现在应该OK
intm=s.GetLength（）;//这个结果可以保证是正确的。
s.TrimRight（）;//将正常工作。
假设你想增加字符串的长度，你首先要知道这个字符串可能会有多长，好比是声明字符串数组的时候用：
charbuffer[1024];
表示1024个字符空间足以让你做任何想做得事情。
在CString中与之意义相等的表示法：
LPTSTRp=s.GetBuffer（1024）;
调用这个函数后，你不仅获得了字符串缓冲区的指针，而且同时还获得了长度至少为1024个字符的空间（注意，我说的是“字符”，而不是“字节”，因为CString是以隐含方式感知Unicode的）。
同时，还应该注意的是，如果你有一个常量串指针，这个串本身的值被存储在只读内存中，如果试图存储它，即使你已经调用了GetBuffer，并获得一个只读内存的指针，存入操作会失败，并报告存取错误。
我没有在CString上证明这一点，但我看到过大把的C程序员经常犯这个错误。
C程序员有一个通病是分配一个固定长度的缓冲，对它进行sprintf操作，然后将它赋值给一个CString：
charbuffer[256];
sprintf（buffer,"%......",args,...）;//...部分省略许多细节
CStrings=buffer;
虽然更好的形式可以这么做：
CStrings;
s.Format（_T（"%...."）,args,...）;
如果你的字符串长度万一超过256个字符的时候，不会破坏堆栈。
另外一个常见的错误是：
既然固定大小的内存不工作，那么就采用动态分配字节，这种做法弊端更大：
intlen=lstrlen（parm1）+13lstrlen（parm2）+10+100;
char*buffer=newchar[len];
sprintf（buffer,"%sisequalto%s,validdata",parm1,parm2）;
CStrings=buffer;
......
delete[]buffer;
它可以能被简单地写成：
CStrings;
s.Format（_T（"%sisequalto%s,validdata"）,parm1,parm2）;
需要注意sprintf例子都不是Unicode就绪的，尽管你可以使用tsprintf以及用_T（）来包围格式化字符串，但是基本思路仍然是在走弯路，这这样很容易出错。
CStringtochar*之三：
和控件的接口；
我们经常需要把一个CString的值传递给一个控件，比如，CTreeCtrl。
MFC为我们提供了很多便利来重载这个操作，但是在大多数情况下，你使用“原始”形式的更新，因此需要将墨某个串指针存储到TVINSERTITEMSTRUCT结构的TVITEM成员中。
如下：
TVINSERTITEMSTRUCTtvi;
CStrings;
//...为s赋一些值。
tvi.item.pszText=s;//Compileryellsatyouhere
//...填写tvi的其他域
HTREEITEMti=c_MyTree.InsertItem（&tvi）;
为什么编译器会报错呢？
明明看起来很完美的用法啊！
但是事实上如果你看看TVITEM结构的定义你就会明白，在TVITEM结构中pszText成员的声明如下：
LPTSTRpszText;
intcchTextMax;
因此，赋值不是赋给一个LPCTSTR类型的变量，而且编译器无法知道如何将赋值语句右边强制转换成LPCTSTR。
好吧，你说，那我就改成这样：
tvi.item.pszText=（LPCTSTR）s;//编译器依然会报错。
编译器之所以依然报错是因为你试图把一个LPCTSTR类型的变量赋值给一个LPTSTR类型的变量，这种操作在C或C++中是被禁止的。
你不能用这种方法来滥用常量指针与非常量指针概念，否则，会扰乱编译器的优化机制，使之不知如何优化你的程序。
比如，如果你这么做：
constinti=...;
//...dolotsofstuff
...=a[i];//usage1
//...lotsmorestuff
...=a[i];//usage2
那么，编译器会以为既然i是const，所以usage1和usage2的值是相同的，并且它甚至能事先计算好usage1处的a[i]的地址，然后保留着在后面的usage2处使用，而不是重新计算。
如果你按如下方式写的话：
constinti=...;
int*p=&i;
//...dolotsofstuff
...=a[i];//usage1
//...lotsmorestuff
（*p）++;//messovercompiler''sassumption
//...andotherstuff
...=a[i];//usage2
编译器将认为i是常量，从而a[i]的位置也是常量，这样间接地破坏了先前的假设。
因此，你的程序将会在debug编译模式（没有优化）和release编译模式（完全优化）中反映出不同的行为，这种情况可不好，所以当你试图把指向i的指针赋值给一个可修改的引用时，会被编译器诊断为这是一种伪造。
这就是为什么（LPCTSTR）强制类型转化不起作用的原因。
为什么不把该成员声明成LPCTSTR类型呢？
因为这个结构被用于读写控件。
当你向控件写数据时，文本指针实际上被当成LPCTSTR，而当你从控件读数据时，你必须有一个可写的字符串。
这个结构无法区分它是用来读还是用来写。
因此，你会常常在我的代码中看到如下的用法：
tvi.item.pszText=（LPTSTR）（LPCTSTR）s;
它把CString强制类型转化成LPCTSTR，也就是说先获得改字符串的地址，然后再强制类型转化成LPTSTR，以便可以对之进行赋值操作。
注意这只有在使用Set或Insert之类的方法才有效！
如果你试图获取数据，则不能这么做。
如果你打算获取存储在控件中的数据，则方法稍有
升级会员 