Check out the Latest Articles:

A good debugger is crucial to strong software development. Having worked with gdb and a variety of freeware debuggers, I feel confident in saying that Visual Studio 2005’s debugger provides a set of features unmatched by many.

Let’s look at how Visual Studio 2005 displays an STL data type as a solid example. Debugging a std::vector is a great experience; you can view each element in the object as though it were listing elements from a static array. You can also directly modify individual items within the object as needed.

STL Vector Debugger View

Visual Studio supports the entire set of STL objects in its debugger. Sadly, this nicety does not extend to custom types and as such you are forced to write hacks like ptr,5 in order to display five elements from ptr in the same way as above.

In this first part of a series, I am going to describe how to get your objects supported by the Visual Studio debugger and make your overall debugging experience a better one by using an undocumented script named autoexp.dat.

Autoexp.dat

Let’s start off by finding the file. Assuming that you are running Visual Studio 2005, autoexp.dat will be in

%ProgramFiles%\Microsoft Visual Studio 8\Common7\Packages\Debugger.

Back up the file somewhere; you don’t want to accidentally lose support for the STL classes.

Within autoexp.dat is a clutter of information. The file’s overall structure follows that of a .ini file in that it uses [section name] blocks to declare the start of a new section. The section we care about right now is the [Visualizer] section.

Once you’ve found your way to the Visualizer section, take a look at the syntax for std::vector or std::basic_string. The basic description for a visualizer of the type “typename” is

typename{
  children
  preview
  stringview

}

Some things to note:

  • Each section is optional. e.g. it is possible describe a type using only the preview section.
  • Syntax is semi-strict. You can not place the curly brace on the next line, it must be in-line with the typename, otherwise Visual Studio will silently ignore that type.

Let’s look at each individual section.

Preview

The preview section lets you describe what will be shown on the same row as the variable. As an example, check out the default view of a RECT structure.

View of the RECT structure

Glancing at this structure is nice in that we can see the values of each member, but it’s devoid of any further meaning. For example, to know the dimensions of the rectangle we have to manually calculate right-left, bottom-top. This may be acceptible for some, but I personally prefer to let the computer do what it’s best at. Let’s use the preview section to make the RECT structure a bit more personable.

tagRECT{
  preview (
    #(
       "Size ",
       $c.right - $c.left,
       "x",
       $c.bottom - $c.top
     )
  )
}

Throw this code into your autoexp.dat file somewhere after the [Visualizer] line but before the [hresult] line. Then try running the RECT test project, placing a breakpoint on the return 0 statement. You should be able to check out the dimensions variable and be greeted with a nice view like so:

Better view of the RECT structure

As you can see, the preview now shows “Size 55×41″. Quite handy if you ask me. Let’s quickly go over the syntax that was used to do that.

  • It is not immediately obvious, but there are two forms of braces being used in the code given. Curly-braces wrap the type’s information in a block, while parenthesis are used for sub-section blocks. The parser isn’t so picky in the sub-sections, allowing you to place parenthesis on separate lines, but for the sake of consistency all braces here will be in-line.
  • Within the preview block we describe the data within a #( ) block. This syntax denotes that we are going to have more than one comma-delimited item within the list. If you plan on only having one item then you can do away with the #( ) block.
  • $c is the current variable that we are looking at. You can use this as you would in code and access any data within the type.

The preview section is hard-limited in size – you can’t write any short stories or sonnets to yourself sadly – but this puts an emphasis on succinctly describing your custom data types. If you need to display any more information than a quick summary, then the children section will help you in that task.

The next article in this series will cover the children section by giving more concrete examples and going over any new syntax that is discussed, including array and tree traversals.

Bookmark and Share


  1. Stephen Whitmore on Wednesday 26, 2008

    Hey Jeff — awesome journal. A clean and succinct design, and lots of insightful entries. Aside from your game framework project, have you been working on any games in particular lately?

    Keep up the great stuff!

  2. jverkoey on Wednesday 26, 2008

    Hey Stephen, thanks for the compliments!

    You can dash over to BrainStormGames.org to see our latest endeavors with the Orion engine. We are going to be completing a very small proof of concept for this Thursday that I may bring to show tonight at the game design club meeting.

  3. Vicky on Wednesday 26, 2008

    Very helpful article! The only thing I don’t like is the promise of a ‘next article in this series’ which I can’t find… Does the rest of the series exist? Please tell me it does…

  4. jverkoey on Wednesday 26, 2008

    Hey Vicky,

    This article was a victim of my sudden switch from C++ development to web development. I can definitely go back and flesh out the second part of this article at some point though!