views:

184

answers:

6
+7  Q: 

View return value?

Say I have the following

int num = 40 + str2Int("30");

Is there anyway with visual studio 2008 to tell what Str2Int is returning without stepping into the function and going to the return?

A: 
cout << Str2Int("30") << endl;

Or!

cout << (num - 40) << endl;
Sapph
+1  A: 

The right way to program is to always be writing small snippets of code to test how things work. For example, if you want to study the str2int function (just as an example, as you said), create a test file just for it. Run it with different parameters, study how it works. Then, you'll be finally convinced that it's working correctly and won't be needing to step into it inside expressions. Once programmers become familiar with tools, they trust them and don't have the need to always be checking how they work.

Moreover, if this is a function you've implemented, the direct corollary of the above is to create a file with unit tests for it. Unit tests exercise the function in various ways until you can trust it's indeed working.

Eli Bendersky
*Once programmers become familiar with tools, they trust them and don't have the need to always be checking how they work.* : -1. No need to cop an attitude here, he's asking how to get a general kind of info from the debugger. His use of `str2int` illustrates that he *doesn't* suspect the library.
Potatoswatter
@eli - it's not always a matter of trusting the function either. You might have a completely bug-free, 100% trusted function and still want to see what its output is for the simple reason that you don't know what its output is going to be. For example, if I don't know where the file pointer is in a `FILE`, I don't know what `fgetc()` is going to return, but that value might be of interest to me while I'm debugging.
Michael Burr
+2  A: 

You can use the Visual Studio Immediate Window. This will allow you to evaluate various expressions.

MattR
Can you give an example? I can never seem to get expressions to work in it.
A: 

I haven't wanted this since I was on PowerPC, and I don't use Microsoft anything, but you probably want the register list and the assembly code view… MSVC must have those.

Stop at the instruction after the function call (which should be easy to pick out), and according to Wikipedia the return value should be in EAX/RAX. Copy the value (or learn the debugger's syntax for referencing the register) and cast to the appropriate type.

Potatoswatter
+1  A: 

Since the return value is generally in the EAX register, you put the $eax 'variable' in the watch window. When you step over the function call, what's in EAX is what that function returned.

And if you also provide the hr format symbol the debugger will show you the HRESULT or Win32 error message (like "S_OK" or "Access is denied") instead of just the raw number. It can be handy to have each ($eax and $eax,hr) in separate watch entries.

Another useful entry is $err which shows whatever GetLastError() would return (and the hr format symbol can be applied to it - or anything - as well):

$eax
$eax,hr
$err
$err,hr

Note that older versions of the VS debugger might want you to use a @ instead of a $ to start these variables, but a member of the debugger team has stated that $ is preferred to keep things in line with the "Debugging Tools for Windows" toolset (I think that support for @ is deprecated and might be removed at some point).

Michael Burr
+7  A: 

In the "auto" variable windows it will display the result of any operations you just stepped over.

Edit: Removed uncertainty over the location of this (thanks goes to Michael Burr)

Grant Peters
Holy crap - I can't believe I didn't know that! (it's the "Autos" window, BTW). Is this new with VS2008 or has it been there for years?
Michael Burr
+1. I didn't know that either. What a great feature!
wj32
Cool, it shows "Str2Int returned" and then what it returned. Also how do you step operations? Step into just goes into the function and step over just steps the entire line. @Michael, it has been there for a long time. Never noticed a difference between it and locals until now though.
I've known about the Autos windows, but was unaware that it showed the results of functions - I thought that it just showed the subset of local vars that are used in the vicinity of the current line of code. I generally ignored it, using Locals because the I found the variability of the items displayed less intuitive than the Locals window. Having it show return values is a nice feature I didn't know about.
Michael Burr
I just checked - this has been in the debugger since at least VC6. Wow. I owe Mr. Peters a beer or something.
Michael Burr
@high6: You can use the "step over" command to advance to the next line of code without stepping into any functions (bound to F10 on my setup, F11 for step over). Then there is the "step out" command which basically run the program till it exits the current function. I highly recommend you check out the commands under "Debug.Step..." as there are some really useful ones there including stepping by instructions (good for the really fiddly debugging). There is also some more advanced features where you can specify functions to never step into, but I can't remember how/where you do that.
Grant Peters
@Grant - specifying functions to not step into is fully supported (I think) in the .NET languages, but in native C++ it's an undocumented stepchild. See Andy Pennell's article about the various ways to do it in C++: http://blogs.msdn.com/andypennell/archive/2004/02/06/69004.aspx Apparently there may be some problems with it in pre-SP1 VS2008 (http://stackoverflow.com/questions/1091835/what-is-the-priority-on-nostepinto-entries-in-vs2008)
Michael Burr
Just figured it out. You can set how the debugger steps over be it instructions or lines via Debug.StepBy. Simply put that in the command window and it will show all of them. Although I don't know how to figure out what instruction is about to be executed.