views:

138

answers:

3

Hi,
A while ago I read the Debugging Windows Programs book, and one of the tricks that it talked about extensively was calling functions from the Visual C++ debugger (quick)watch window. As luck would have it, I don't have a copy on hand and the little documentation that I could find about this is really really poor.

So how DO you call a member function in the watch window? What if the function lives in a DLL? What if it is part of a namespace? Can you pass non-trivial parameters?

Let's use this example: I want to call the size() method of QList<MyType>, where MyType is a custom type.

Thanks!

A: 

Are you sure that you can call methods of objects while debugging code in Visual Studio? Because I was never able to do so. The closest debugging features I know is to have a quick watch on objects (including local objects in the stack, navigating through the call stack), or compile and continue (I used it in VC6) allowing to change the code, recompile and continue debuging from the last statement...

Cătălin Pitiș
Yup, I just called one. While in class X, I called X::returnAQString() by typing returnAQString() and I can look at the QString in the debugger.
rpg
Good to know... I have to try it :)
Cătălin Pitiș
+1  A: 

I'd say just write list.size() in the watch window, where list is an instance of your QList, but I'm not sure this works for all classes

stijn
Scratch that, it works. I was calling size() on a QVariant called "list". :-)
rpg
+2  A: 

It works and is hugely useful. You can evaluate expressions in the watch window or open the quick watch window (ctrl-alt-Q -- a very handy shortcut to know). It will let you call most forms of member functions. The only times it commonly tends to fail is if you've got overloaded operators, eg with smart pointers. For a simple class without overloaded operators you should find it should work well. I think it should accept non-trivial parameters (though obviously it depends how non-trivial!) As well as calling functions that return values, you can also call functions that modify the object -- there's no constraint on only calling getter methods.

The other kind-of-obvious thing to remember is that all variables are evaluated in the local stack frame, so ensure the variable is visible from the current point in the stack.

the_mandrill