为什么CString.Empty()或CString = L""导致变量中的垃圾? [英] Why does CString.Empty() or CString = L"" cause garbage in the variable?

查看:763
本文介绍了为什么CString.Empty()或CString = L""导致变量中的垃圾?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个奇怪的问题。它只发生在一个特定的解决方案中,当我在另一个较小的解决方案中尝试这个时,它似乎工作正常。但是在我更大的解决方案中,如果我将CString定义为:

I'm having an odd problem. It's only happen with one particular solution and when I try this in another, smaller, solution it appears to work fine. However in my larger solution if I define a CString as:

CString sTestString;

在调试器中查看它我看到sTestString在定义之后的值是我正在运行的.exe的可执行路径。如果我尝试用.Empty()或'= L"" ;;'来清空它,即使在清空它之前字符串
中还有其他值,在空字符串包含可执行文件之后路径。 

Looking at it in the debugger I see that the value of sTestString right after being defined is the executable path of the .exe I'm running. If I try to empty it, either with .Empty() or '= L"";', even if there was some other value in the string prior to emptying it, after the empty the string contains the executable path. 

还有其他人见过这样的事吗?

Has anyone else seen anything like this?

谢谢,

Rob

推荐答案

是使用调试版还是发布版构建的?你有隐藏在该代码中的名字吗?该代码的范围是否有任何变化?

Is it built using the debug or release configuration? Do you have name hiding in that code? Is there any changes in scope in that code?

显然,有了这些小信息,可以说很少,但是如果变量失效,优化器可以重复使用内存。范围。

Obviously, with this little information there is very little that can be said, but the optimiser can do tricks in reusing memory if variables go out of scope.

如果您在使用发布配置构建的可执行文件中看到这一点,尤其如此,请尝试查看是否与使用调试配置构建的版本一起发生,这几乎都是优化已关闭。

So this is especially true if you are seeing this in an executable built with the release configuration, try seeing if it happens with the version built with the debug configuration, this has almost all optimisations turned off.


这篇关于为什么CString.Empty()或CString = L""导致变量中的垃圾?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆