消息值，托管字符串，扰乱代码及其它

核心提示： C:\>StrTime3 50000000Test 1: Allocate 50000000 strings using LPCTSTRTotalMemory = 190952， time: 33147 msecTest 2: Allocate 50000000 strings us

C:\>StrTime3 50000000
Test 1: Allocate 50000000 strings using LPCTSTR
TotalMemory = 190952， time: 33147 msec
Test 2: Allocate 50000000 strings using .NET S literal
TotalMemory = 43484， time: 110 msec

正如你所看到的，5000万个托管 String 只占有了非常少的空间——特别是当真正只有一个时！尽管用TCHARs，垃圾收集器仅用了 190,952 字节。高等数学推理会得出5000万字符串 无法装入 191 KB，因此可以肯定地说：Framework 在垃圾收集装置里安装了一些机关。

最后我担心我的所有测试程序都没有回答你的问题——使用托管 String 文字量到底有多快？没有微妙或纳秒粒度的计时器就不可能说清楚这个问题。但是至少我的研究可以帮助你理解表象下面 所发生的一切，从而你可以明白为什么 ldstr 比 newobj 有更加显著的效率。

因此，你要使用哪种类型的文字量呢？事实是：用户可能绝不会注意到其中的差别。但是无论何处你调用一个使用 String 的函数最好是用 S 类型文字量。注意在 MFC 中，因为可以交替使用 LPCTSTR 和 CString，你不能将传递 String 给需要 TCHARs 的C/C++函数。那是因为托管字符串总是 Unicode (宽字符)，并且从 String 到 wchar_t 没有自动转换机制。因此，你需要在 vcclr.h 中提供的 PtrToStringChars函数。下一个问题示范了一个这方面的例子。

关于托管的和原生的字符串文字量最后要注意的一个小问题是：如果你检查在 Figure 3 和 Figure 4 中的ILDASM 代码，你会看到虽然文本 "This is a String literal" 在反汇编代码中清晰可见，而表示 C++ 文字量 "This is a TCHAR string" 的文本却无处可寻。它被隐藏在一个神秘变量中了 A0x1f1e2151.unnamed-global-0。这是否意味着 C++ 文字量提供了更大迷惑性——就是说，让你可以在众目睽睽之下隐藏你的字符串？实际并不如此，Figure 3 中的 MSIL 代码报告了神秘的 "unnamed-global-0" 是 在 "D_0000B14C."。出于好奇，我在一个十六进制查看程序中查看了 StrLit.exe，果真有这个串，确切位置在 0xB14C。Figure 6 展示了十六进制程序显示多所有东西：