views:

2460

answers:

3

I want to add a breakpoint condition to my code in VC++ Express 2005, so that the breakpoint only triggers if a local variable meets a specified criteria. e.g.

bool my_test(UIDList test_list) {
    foo(test_list);
    bar(test_list); // I have a breakpoint here, but only want it to trigger if test_list.Length() > 0
    print(test_list);
}

Having right-clicked on my breakpoint and selected "Condition..." I have found a dialog that appears to do what I want, however anything I try typing into the text field results in the following error:

Unable to evaluate the breakpoint condition: CX0052: Error: member function not present

I tried the help documentation, but I couldn't find my answer. I'm hoping someone experienced in VC++ might be able to point me in the right direction...

I have previously tried upgrading to a more recent version of VC++ Express, but the project did not import cleanly. Due to the complexity of the project and my current time scales I can't consider upgrading as a solution at this point.

+3  A: 

The conditions in a breakpoint can't call methods as far as I know. So, what you need to do is to calculate the length before hand. Something like this.


bool my_test(UIDList test_list) {
 foo(test_list);
 int i = test_list.Length();
 bar(test_list); // I have a breakpoint here, but only want it to trigger if test_list.Length() > 0
 print(test_list);
}

Put a conditional breakpoint on the value of i here and you should be fine.

Aamir
+5  A: 

use the DebugBreak(); function:

bool my_test(UIDList test_list) {
    foo(test_list);
    if (bar(test_list) /* or whatever check :) */) // I have a breakpoint here, but only want it to trigger if test_list.Length() > 0
        DebugBreak();
    }
    print(test_list);
}

Or you can always use assert(expression)

bool my_test(UIDList test_list) {
    foo(test_list);
    bar(test_list);
    assert(test_list.Length() > 0); // will break here
    print(test_list);
}
Stormenet
+4  A: 

VS does have some micro-evaluation engines- in variable watch windows, immediate window, break point conditions etc. I could never find decent documentation on them. As far as i can tell they are picky about methods they're willing to call, but they're also insensitive to access limitations.
So, you can probably rephrase your condition from

test_list.Length() > 0

to something like

test_list.m_nLength > 0

(or whatever your private length var is).

(EDIT) Just found this msdn page explaining what expressions the debugger can and can't handle. So first, indeed -

'The debugger can access all class members regardless of access control. You can examine any class object member, including base classes and embedded member objects.'

And second, my guess regarding the failure to evaluate 'Length()' - it was probably inlined:

'A debugger expression cannot call an intrinsic or inlined function unless the function appears at least once as a normal function.'

Ofek Shilon