programming
April 16, 2010 10:39 AM Subscribe
Is there a tool to help visualize/show the steps of the complex loops I'm writing in c/c++?
I'm using Visual Studio 2008 to write some pretty complex loops, and I'm having trouble figuring out my mistakes, what goes where when, etc. I'm creating files, so I can use a hex editor and copy and paste into excel and work from there, but it's a huge hassle, and not really built for that sort of thing. Any suggestions?
I'm using Visual Studio 2008 to write some pretty complex loops, and I'm having trouble figuring out my mistakes, what goes where when, etc. I'm creating files, so I can use a hex editor and copy and paste into excel and work from there, but it's a huge hassle, and not really built for that sort of thing. Any suggestions?
Use the debugger while the program is running. Set breakpoints where you suspect there are issues and work from there.
posted by knz at 10:47 AM on April 16, 2010 [1 favorite]
posted by knz at 10:47 AM on April 16, 2010 [1 favorite]
Log statements or debugger.
posted by Blazecock Pileon at 10:48 AM on April 16, 2010
posted by Blazecock Pileon at 10:48 AM on April 16, 2010
Several people have posted about using a plugin from Microsoft's Phoenix tools to generate control flow graphs. There's no way in Hell that will turn out to be easier than just stepping through it all and documenting the loop invariants, but it does exist if you're feeling adventurous.
posted by ecurtz at 10:55 AM on April 16, 2010
posted by ecurtz at 10:55 AM on April 16, 2010
Woah... yeah, you shouldn't be needing to mess with hex editors and Excel. Get to know your debugger. Seriously -- this is what it's made for, and once you figure it out your life will never be the same.
If one isn't available, print out the status of each trouble spot when you get to it, so you can see the program flow as it executes. Tab each outputted line so you can easily tell which level of a nested loop you're in.
posted by cgg at 11:02 AM on April 16, 2010
If one isn't available, print out the status of each trouble spot when you get to it, so you can see the program flow as it executes. Tab each outputted line so you can easily tell which level of a nested loop you're in.
posted by cgg at 11:02 AM on April 16, 2010
Use the debugger while the program is running. Set breakpoints where you suspect there are issues and work from there.
Specifically with Visual Studio:
- To start your app with debugging enabled, just set your configuration to Debug (it should be in a dropdown box), rebuild, and click the green start button to start debugging.
- Click on the grey area to the left of a given line of code to set a breakpoint. The code will pause when it hits these lines and highlight them, until you continue.
- When the program is stopped by a breakpoint or by you clicking the pause button, you can Step Into lines (meaning if a function is called, step through that function) or Step Over lines (meaning always move to the next line without stepping into other functions) using F10 and F11.
- Also, when the program is paused, you can right click on a line of code and choose "Run to cursor" which means run to that line of code and then stop, this is like a one time use breakpoint. Also, you may be able to drag the yellow arrow that shows what line you are executing to other lines so that you can execute random lines of your code, but I'm not sure if that works for C/C++.
- You should also be able to mouse-over variables when paused to see what their values are, and you can change those values in the Locals window.
posted by burnmp3s at 11:19 AM on April 16, 2010
Specifically with Visual Studio:
- To start your app with debugging enabled, just set your configuration to Debug (it should be in a dropdown box), rebuild, and click the green start button to start debugging.
- Click on the grey area to the left of a given line of code to set a breakpoint. The code will pause when it hits these lines and highlight them, until you continue.
- When the program is stopped by a breakpoint or by you clicking the pause button, you can Step Into lines (meaning if a function is called, step through that function) or Step Over lines (meaning always move to the next line without stepping into other functions) using F10 and F11.
- Also, when the program is paused, you can right click on a line of code and choose "Run to cursor" which means run to that line of code and then stop, this is like a one time use breakpoint. Also, you may be able to drag the yellow arrow that shows what line you are executing to other lines so that you can execute random lines of your code, but I'm not sure if that works for C/C++.
- You should also be able to mouse-over variables when paused to see what their values are, and you can change those values in the Locals window.
posted by burnmp3s at 11:19 AM on April 16, 2010
Try to simplify your loops! Split chunks of code off into functions with meaningful names.
Also, "never underestimate the debugging power of printf". Liberally sprinkle your code with bits of debug text. Try to make this meaningful as well, though I for one have often just had programs print out "POOP" or "HI" or whatnot when I'm just trying to make sure they're actually executing certain parts.
posted by egypturnash at 1:10 PM on April 16, 2010 [2 favorites]
Also, "never underestimate the debugging power of printf". Liberally sprinkle your code with bits of debug text. Try to make this meaningful as well, though I for one have often just had programs print out "POOP" or "HI" or whatnot when I'm just trying to make sure they're actually executing certain parts.
posted by egypturnash at 1:10 PM on April 16, 2010 [2 favorites]
Brute force way: put a compiler switch on an inline macro print message, that conditionally increments or decrements a tab value, so at least the diagnostics are indented to show loop structure.
posted by StickyCarpet at 1:22 PM on April 16, 2010
posted by StickyCarpet at 1:22 PM on April 16, 2010
I'd like to build on egypturnash's statement of:
Try to simplify your loops! Split chunks of code off into functions with meaningful names.
The value is two-fold.
1) You can more easily understand your loops; they're shorter, with well-named, meaningful sub-problems.
2) You can independently test each of these smaller functions, so you can be more confident that they actually work, leaving you to worry about the code that uses them
posted by alexallain at 5:26 PM on April 16, 2010
Try to simplify your loops! Split chunks of code off into functions with meaningful names.
The value is two-fold.
1) You can more easily understand your loops; they're shorter, with well-named, meaningful sub-problems.
2) You can independently test each of these smaller functions, so you can be more confident that they actually work, leaving you to worry about the code that uses them
posted by alexallain at 5:26 PM on April 16, 2010
The obvious quote-reference for this question:
The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. - Linus Torvalds
posted by tmcw at 6:23 PM on April 16, 2010
The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. - Linus Torvalds
posted by tmcw at 6:23 PM on April 16, 2010
This thread is closed to new comments.
posted by ish__ at 10:44 AM on April 16, 2010