在Visual C ++中进行调试 [英] Debug in Visual C++

查看:96
本文介绍了在Visual C ++中进行调试的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Visual C ++中的程序中,有时当我编写新代码,生成并运行时,它不起作用.但是,当我添加断点时,在debugger中运行,它会给出正确的答案.

因为只有几分钟的时间,我向经理展示了我的工作,在那里我被要求输入新的值进行测试n在他离开后再也没有用过,我在调试器中进行了测试n可以了!

我第五次遇到这种情况.有人知道为什么吗?

解决方案

最常见的情况是,您的Debug版本无法正确运行,而Release版本却无法正常运行运行,是由于使用了诸如以下的构造:

ASSERT(a = func());

在发行版本中,未调用"func"-实际上,整个ASSERT语句被替换为空.

除非根本没有时间敏感的实时应用程序,否则执行速度根本不可能. br/>
当您将活动窗口切换到调试器时,它是否起作用?

您确定每次都运行相同的二进制文件吗?在这种情况下,有时我会删除所有dll/exe文件,然后重新生成并运行

如果您正在运行发布或调试,可能是因为以下原因:

一个普遍的问题是,在构建发行版时,您可能会在未初始化的变量中获得不同的值,例如以下行为会有所不同

 BOOL myBool

如果(myBool)
   // 这将是发行版中的路径
其他
   // 这将是调试路径

无效 * pMyPointer

如果(pMyPointer)
   // 这将是发行版中的路径
其他
   // 这将是调试中的路径 


原因是调试器将内存清零,在释放模式下内存包含先前的数据,这就是为什么初始化变量很重要的原因

例如

 BOOL myBool = FALSE;
pMyPointer =  nullptr ; 


根据您使用的VC ++版本,调试器可能会不同地初始化内存从您从外壳程序运行它时开始.因此,您可能正在某个不应该使释放模式版本崩溃的地方进行读取/写入,但是由于调试器在其中的任何投入,它恰好是有效的...

快速提示:

-不要在95%的时间内使用调试器,而是在每次构建时使用单元测试来验证代码并运行它们
-分叉以获取PClint的副本,并使用它来检查您的代码是否在做顽皮的事情-例如取消引用未初始化的指针
-使用您可以获得的最新编译器,较新的编译器可以更好地警告危险事项

干杯,


In my programs in Visual C++, sometimes when I write new code, build and run,it doesn''t work. But when I add break points, run in debugger , it gives the right answers.

Because just couple of minutes back I was showing my work to my manager, where in I was asked to put new values for testing n it never worked n later after he left, I tested in debugger n it worked!!

I''m experiencing this kind of behaviour for the fifth time .Does anyone know why ?

解决方案

Most commonly, your problem of Debug build running correctly and Release build not running, is due to using constructs such as:

ASSERT (a = func());

In release version "func" is not called - in fact the whole ASSERT statement is substituted with nothingness.

Execution speed unless you have a very time-sensitive real-time application is NOT likely at all.


Is it that you break point is holding things up long enough for some precondition to happen?

Is it that it work when you switch active windows to the debbuger?

Are you sure your running the same binaries each time? in this situation I sometimes delete all occurances of my dlls/exe then rebuild and run

If you are running release or debug Could this be the reason:

One common problem is when you build release you can get a different value in variables that are not initialised e.g. the following will behave differently

BOOL myBool

if (myBool)
   // this will be the path in release
else
   // this will be the path in debug

void* pMyPointer

if (pMyPointer)
   // this will be the path in release
else
   // this will be the path in debug


The reason for this is that the debugger zeros memory, in release mode the memory contains previous data this is why it is important to inialise varables

e.g.

BOOL myBool = FALSE;
pMyPointer = nullptr;


Depending on what version of VC++ you''re using the debugger might initialise memory differently from when you run it from the shell. So you might be reading/writing somewhere you shouldn''t which crashes the release mode version but due to whatever the debuggers throwing in there it happens to be valid...

As a quick set of tips:

- Don''t use the debugger 95% of the time, use unit tests to verify your code and run them every time you build
- Fork out for a copy of PClint and use it to check that you''re not doing something naughty in your code - like dereferencing an uninitialised pointer
- Use the latest compiler you can get, newer compilers are better at warning about dangerous things

Cheers,

Ash


这篇关于在Visual C ++中进行调试的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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