CString是否始终以null结尾？

Question

从CString接口，显然不应该假设CString是空终止的。但是，似乎有时在字符串的末尾有一个空字符。 是否有可能，在Windows实现，创建一个CString，做不有一个空字符，使阅读一个字符过去字符串的结尾是在寻找一个不同的堆对象？

Answer 1

看看这里的MSDN文档：

http://msdn.microsoft.com/es-es/library/awkwbzyc(v=vs.80).aspx

基础上，我会想有一个空终止那里你只需要做一些铸造得到它。

Answer 2

是，CString的总是空终止。

的文档指出，你可以投一个CString到LPCTSTR，LPCTSTR和是的typedef之一：
__nullterminated CONST WCHAR *
__nullterminated CONST CHAR *
取决于UNICODE是否定义或没有。

Answer 3

演员到LPCTSTR将提供一个null结尾的字符串，但不能保证该字符串的是，转换之前空值终止。它可以很容易地终止函数内的字符串。

的CString的来源是由微软提供，以确保是看那里，看看事情究竟是如何实现的最佳途径。当然，它可以在下一个版本中改变 - CString多年来发生了不少变化。

Answer 4

一个CString更像是一个Visual Basic字符串或BSTR。它可以在CString的数据部分包含嵌入的二进制零。但是，当使用各种运算符在CString和标准C型零终止字符串之间进行转换时，嵌入式二进制零将被视为字符串字符的结尾。所以一个CString就像一个BSTR类型的变量。

比如我把下面的源代码行成一个MFC项目，并在Visual Studio C++调试运行它。

CString myString (_T("this\000is a String.")); // myString will only contain "this" as a zero terminated string. 

CString myJJ; 
myJJ.Format (_T("this%cisaxxx"), 0); // this creates a string with an embedded binary zero in it. 
int iLen = myJJ.GetLength();  // this returns the length of the complete string, 11 characters 
CString myRight = myJJ.Right(4); // this returns the right most 4 characters, "axxx" 
TCHAR myTbuff[64]; 
_tcscpy (myTbuff, myJJ); // this copies the string up to the embedded binary zero into myTbuff 

至于去下一个堆对象，我不会依赖于此。实现CString关于对象如何布置在内存中以及它如何使用内存。如果你创建一个CString，可能会分配一个大小为64个字符的缓冲区，而不管你输入了多少个字符。 CString提供了GetLength()方法来确定CString中应该使用多少个字符。还有获取和设置特定字符位置的方法。

CString旨在允许程序员像在Visual Basic类型的字符串中一样思考字符串，而不必处理C样式字符串，这些字符串是真正的字符数组，具有字符串终止符字符的特殊结尾，二进制零。

Edit01 - 在CString的编译参数和效果

在Visual Studio编译器以前到Visual Studio 2013允许CString类来创建或者8位多字节字符集或16位的Unicode字符串取决于是否处理源文件时定义_MBCS或_UNICODE。

我之前说过的Visual Studio 2013的原因是，似乎现在不推荐使用_MBCS（另请参阅Side-effect of deprecation of MBCS support for MFC in VS 2013）。

的这种灵活性的根是TCHAR定义其可以是char如果_MBCS被定义或wchar_t如果_UNICODE定义。这反过来决定了_T()或TEXT()宏会发生什么情况，该宏会将引用的字符串转换为char类型的数组或类型的数组，其中L用于指示wchar_t文本字符串。这也会影响LPCTSTR（指向const TCHAR字符串的指针）或LPTSTR（指向非const TCHAR字符串的指针）的实际类型。

与Windows NT/2000/XP一样，Windows 95/98/ME在Windows API中没有对UNICODE的本地支持，因此允许选择UNICODE以将Windows NT或MBCS作为目标Windows 95是有帮助的。当时的另一个选择是用于Unicode的Microsoft Layer，它为Windows 95/98/ME的Windows API提供了一个UNICODE接口。