At some point I really got tired of hitting SHIFT+F11 to jump out of another section of code that I knew, wasn’t really the problem.

I found an interesting article about preventing the visual studio debugger from stepping into certain areas of your code, that I would like to share with you:
http://blogs.msdn.com/andypennell/archive/2004/02/06/69004.aspx

Note that in case you use a x64 based system you will need to place the registry information into the HKLM\Software\Wow6432Node\Microsoft\VisualStudio\8.0\NativeDE entry (you can read more about this at http://support.microsoft.com/kb/896459).

So this is what I use on my Windows7 x64 installation running Visual Studio 2005:

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\8.0\NativeDE\StepOver]
"no boost"="boost\\:\\:.*=NoStepInto"
"no stl"="std\\:\\:.*=NoStepInto"

The VisualStudio expression engine makes this an easy task (no need to brush up your assembler knowledge on this one) just enter the function signature into your watch window. Note that you will need to fully qualify any namespaces.

If your project consists of multiple modules, or when you use the same function signature in different compilation units you will have to tell the debugger where to find the symbol.
For this the context operator {[function],[source],[module] } location is defined.
You should have a look at the reference[1] over at MSDN to familiarize yourself with the syntax.

[1] – The context operator – http://msdn.microsoft.com/en-us/library/wztycb7f%28VS.80%29.aspx

One feature that I was missing of late was the concept of hierarchical breakpoints.
Often during debugging I want the debugger to break in some method or function but only coming from an specific path.

To give you an example:

void some_function() {
/* breakpoint here */
}
 
void some_other_function() {
/* breakpoint here */
    some_function();
}
 
int main(int argc, char* argv[])
{
    some_function();
    some_other_function();
    return 0;
}

What I’d like to do now is to break in “some_function” but only coming from “some_other_function”.
In this easy example I could happily press F5 a couple of times and be done with it. I could also use the breakpoints hit-counter to accomplish that goal.
But for more complex software this quickly becomes unpractical.

Luckily for me Visual Studio provides an rich extension framework.

You see two breakpoints in the image above. By Draging’n'Droping the breakpoint in line 7 on the one in line 11 the one in line 7 got disabled. Once the program hits line 11 during a debug run the AddIn will in turn enable all child breakpoints (the one in line 7 in this case).

tutorial

We have created a quick tutorial video here.

download

You can download the project (source only) from sourceforge. Drop me a visit at ohloh if you like the software.

Well here would be the solution for C/C++ sources at least (in visual studio regular expression dialect).

So just fire up your CTRL+H, search and replace dialog and strip away. Maybe you will find it wise to create a copy of your project beforehand in case I missed something.

(/\*(\n|.)@\*/)|(//.*$)

If you are interested in the visual studio specific dialect of regular expressions please have a look at this msdn reference.

On that note, I’d like to point you to an interesting link where you will find a coding standard generator. After choosing from a lot of options your will end up with an generated document that can serve pretty well as a draft four your own needs.

To make compliance with that standard easier for me and my fellow co-workers, I have created an astyle configuration file and let astyle (A Free, Fast and Small Automatic Formatter) run over my code every time I create a build (visual studio pre-build event). At least for my current project, the amount of time needed for the tool to crawl all my files does not become noticeable on my machine.

For sure astyle is no silver bullet. There where a couple of incidents where code wasn’t correctly formatted (at least not by our definition) and we would have to customize the tool a bit. Changing astyle to fit your needs however is pretty straight forward. What you gain however is that everybody is more or less free to code as he is used to. The result will always conform to the same standard since everybody’s code is formatted after a predefined set of rules.

At least for us this approach proved beneficial.

To get rid of them all press CTRL+H (the default hotkey) to fire up the search+replace dialog. In the find options select Use: Regular expressions as the search method. In the search textfield enter ^$\n and leave the replace with text field empty. Select the scope where search+replace should take place in the “Look in” drop down box. Now, fire away.

As a short hint as to what the expression actually means:
^ = match the beginning of an line
$ = match the end of a line, but not the linefeed character
\n = match the linefeed