I hate the Visual Studio debugger with a passion. Other than setting static breakpoints and browsing primitive data types it seems to fall down. I was trying to set a conditional data breakpoint and it never triggered. So I wrote a simple program that I felt should not fail to break: I then set a conditional data breakpoint on s to break if it's size is greater than 10. I set it by highlighting s, RMC/New Breakpoint..., select the Data tab, hit the "Condition..." button and entered the expression s.size() > 10: I run the program and it never breaks. If I'm doing something obviously wrong, other than using Visual Studio, please let me know. BTW, I tried this in VS2003 and VS2005 Aug CTP

Thanks for the reply! I know that digging into the internal data structure will work in this case but unfortunately in my "real" case the method does more than simply return a value. I was just trying to cook up a simple case since the complex case seemed to be failing.

The odd thing is that is that it seems to be called. In this simple example with the breakpoint in place it takes about 30 seconds to run the program. With no breakpoints it takes about 5 seconds to run.

Even though it's alot slower it does not seem to call it. I set a breakpoint in _String_base::size() and it's never called.

Damn debugger.

Is Visual evaluating s.size() everytime it hits the break point or not ?

I'd come to the same conclusion as brataccas, you cannot set a breakpoint on a class, you have to set it on one of its data members. However, even if you do that it appears that the debugger's conditional evaluator cannot call functions or methods like the other evaluation fields in Visual Studio can.

I find this puzzling as one of the cannonical examples of conditional breakpoints for debuggers in general is a C-style string check like: strcmp(p, "Cool") == 0.

What I'm really looking for (and what started me down this path) is a generic conditional breakpoint. For example real debuggers like dbx allow you to do things like:

stop -if x > 10

or

stop -if myFunc() > 10

which will evaluate on every program statement the expression. It tends to be slow but it allows you to quickly track down certain classes of bugs easily.

It looks like Visual Studio's debugger does not support this or many other useful debugging constructs that other debuggers have had for over a decade.

The Visual Studio debugger is very shallow feature-wise. It epitomizes the "thin veneer on assembly" style of debugger that barely knows anything about what it is debugging. The nice thing about this type of debugger is it's easy to adapt it to different languages quickly. The bad thing is that it tends to not support debugging constructs natural to a language like stopping in a named method in C++

Visual Studio 2005 appears to be no better at the breakpoint level but at least it now has inspectors for the C++ standard library types. A glaringly obvious feature that should have been in VS6 and was inexcusably missing in VS2002 and 2003.

Sorry for the editorializing but I'm a bit miffed.