开发者

Any way to break only if another break is encountered in Visual C++ 2008?

开发者 https://www.devze.com 2023-04-11 07:31 出处:网络
I have found myself in this situation many times where I need to break into a function that is called hundreds of times only after a particular break-point has been hit.

I have found myself in this situation many times where I need to break into a function that is called hundreds of times only after a particular break-point has been hit.

So let's say there is a function that updates the status of objects. This is called multiple times per frame. I am testing a function that edits an object. As soon as that function is hit, I can then break into the UpdateStatus function. Obviously, if I put a breakpoint in UpdateStatus it will always break and I will never be able to interact with the program. What would be great if I could set a conditio开发者_如何学编程n on the breakpoint to only break if the breakpoint in the other function hit. Note that this is just an example.

I am using Visual C++ 2008.


I remember running into a situation like this myself. I believe you can combine Visual Studio tracepoints with Visual Studio macros to do this pretty easily. This page describes how to write a macro that turns on breakpoints: http://weseetips.com/tag/enable-breakpoint/ Since you want to enable only a single breakpoint, you'll want to use some combination of file and line number in your macro to enable only the breakpoint you want--you can find the breakpoint object members here: http://msdn.microsoft.com/en-us/library/envdte.breakpoint.aspx (File and FileLine look particularly useful)

This page describes how to use a 'tracepoint' to run a macro: http://msdn.microsoft.com/en-us/library/232dxah7.aspx (This page has some nice screenshots of setting up tracepoints: http://weblogs.asp.net/scottgu/archive/2010/08/18/debugging-tips-with-visual-studio-2010.aspx in VS2010)

So you could create a macro that will enable your breakpoint, and create a tracepoint that executes your macro. (You can even add a second tracepoint that disables the breakpoint afterward, so that you can easily repeat the process.)


You might be able to place a conditional breakpoint within the UpdateStatus itself.

Alternatively, place a conditional breakpoint at the call-site of UpdateStatus then perform the step-in manually.

Whether you'll be able to do one or the other (or any at all) depends on how complex the breakpoint condition is and whether input for that condition is "reachable" from the particular stack frame.


You could have the first breakpoint set a flag when hit, then let the second breakpoint check that flag as a condition.
You can set the flag by specifying a "message" to be printed when hit, like so:

{flag = 1;}

flag needs to exist in the scope, of course.
(It would be nice if it was possible to declare a variable that only exists during the debug, but I'm unaware of how to do this.)

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号