Microsoft Visual C++ Tips and Tricks

by Alan De Smet

If you're stuck using Microsoft Visual C++, these tips may help make the experience more pleasant. I've been collecting these little tidbits for a while, and decided to collect them in one spot. I've chosen to collect them here because I can't think of a better spot.

First thing, get yourself a copy of Workspace Whiz. Workspace Whiz gives you a nice GUI interface to Exhuberant CTAGS. It also gives you a handy button to switch between the header and source files. It's cheap ($10), and makes life better.

Next, get yourself a copy of STLFilt. It's completely free. It significantly cleans up the garbage error messages Visual C++ generates for STL code. (It does require Perl, but every developer should have Perl installed anyway. The easiest way to get Perl for Windows is ActiveState's free ActivePerl.

Whenever I refer to the "sharedide" directory, you'll need to change it to the appropriate directory. In Visual C++ 5, it's actually called "sharedide" under the directory where you installed VC. In Visual C++ 6, it's in the "Common\MSDev98" directory under the directory where you installed VC.

Show compile duration

Simply add '/Y3' to the command line of VC (In the short cut). You'll now get reports on how long a compile took in your Build window.

Update 2003-01-10: I haven't had a chance to use Visual Studio .NET yet, but I'm told that you can set this option with a switch under Options > Projects > Build.

Teach VC to intelligently expand classes/structs in debugger

Add user defined keywords for syntax highlighting

Custom Tip of the Day

How to use .cc file extensions for C++

Make the following modifications to the registry:

Add the flag "/Tp" to the compiler settings for the project.

Removing the "docking" capability from the menus

In Tools > Options..., in the Workspace tab, turn on "Use screen reader compatible menus". Your menus will lose the gripper (the double line on the left edge indicating dockability), and will stay nailed down like they should. Unfortunately this also removes the icons from the menus.

Useful build messages

The following macros make it easy to add reminders which are displayed when code is compiled. You can double click on a reminder in the Output Window and jump to the line. Useful for marking TODOs. (Originally from Windows Developer Journal, 1997?)

Once defined, use like so:

#pragma message(Reminder "Fix this problem!")

This will create output like:

C:\Source\Project\main.cpp(47): Reminder: Fix this problem!

Hard code a debugger breakpoint

If you need to insert a hard breakpoint in your code (perhaps because you need to attach to a process), simply add the following line to your code.

__asm int 3;

Tracking GDI resource leaks

Plenty of tools exist to help track down memory leaks. You've got the debug heap, Rational Purify for Windows, HeapAgent, and other tools. But there aren't any good tools to help track GDI resource leaks. A resource leak can crash the system under Windows 95 or Windows 98, and can ruin performance on any Windows operating system.

The article "Resource Leaks: Detecting, Locating, and Repairing Your Leaky GDI Code" is the only real help I've found. In particular, the article includes a program that tracks current globally allocated resources under Windows 95 or Windows 98. You can track what resources were created between a start and stop points, and display what those resources are. Check the article for the download (Leaks.exe).

Update 2003-01-10: The very friendly people at Compuware have pointed out that BoundsChecker will detect GDI resource leaks. At the moment I'm doing Unix development work, so I haven't had a chance to test it myself, but if you're fighting GDI leaks, it might be worth checking out. At the moment it appears to carry a $695 price tag. They offer a trial period. (Regrettably of the "give us your contact info and we'll contact you about a trial" type.)

Memory Values

If you're using the debug heap, memory is initialized and cleared with special values. Typically MFC automatically adds something like the following to your .cpp files to enable it:

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

You can find information on using the debug heap here. Microsoft defines some of the magic values here.

While using the debug heap, you'll see the values:

Watch Values

The watch window has a number of undocumented or minimally documented features that make it even more useful.

Display GetLastError's value and message

You can display the value GetLastError() will return by putting "@err" in your watch window. You can see the error message associated with that value by putting "@err,hr" in your watch window. If you've placed an HRESULT in a variable, adding ",hr" to the variable name in the watch window will display the associated text.

Display pointer as an array

If you expand a pointer and you only get a single item, just add ",n" to the entry in the watch window where n is the number of elements to expand. For example, if you have a foo * pFoo pointing to an array of ten elements, put pFoo,10 in your watch window to see all of the element. This can be useful to view parts of a large array. If pFoo points to an array of 5,000 elements, you might use (pFoo + 2000),10 to see elements 2000 through 2009.

Debug checked casts

If you want maximum safety, you should always use dynamic_cast. However, if you feel you must optimize away those costs, use this version of checked_cast. It will ASSERT on a bad cast in Debug builds, but not do the slightly more expensive dynamic_cast in Release builds.

Don't use SourceSafe

SourceSafe is problematic revision control system. The integration with Visual Studio is not worth the trouble. There are better solutions available. I've written a page with specific details on why Visual SourceSafe is a bad choice.

Unverified

These are notes taken by a David Carley from a video of a talk given by a Microsoft Visual Studio developer. Unfortunately the original video is no longer available (or at least hidden). I haven't verified most of these.

Avoiding Stepping Into Things

It's often useful to avoid stepping into some common code like constructors or overloaded operators. autoexp.dat provides this capability. Add a section called "[ExecutionControl]". Add keys where the key is the function name and the value is "NoStepInto". You can specify an asterisk (*) as a wildcard as the first set of colons for a namespace or class.

autoexp.dat is only read on Visual Studio's start up.

To ignore the function myfunctionname, and all calls to the class CFoo:

To ignore construction and assignment of MFC CStrings: (Notice the extra = in CString::operator=.)

To ignore all ATL calls:

Function Evaluation

Multi-Threaded Debugging

Naming Threads

Use "SetThreadName". The name is limited to 9 characters. SetThreadName fires an exception, which the debugger will catch and use to name the thread. The name will appears in Debug > Threads dialog.

Win32 Exceptions

Breakpoints in System DLLs

Breakpoint on certain argument values

1. Set breakpoint
2. Determine stack offset to argument (see disassembly window)
3. Set condition e.g. dw esp+0x8 == 0xFFFFFFFF

Data Breakpoints

Data breakpoints are very powerful, but suffers from a confusing interface. Avoid entering "emulation" mode if possible, it's very slow.

It's often useful to break on an address: "*(long*)0x1234ABCD, length = 1".

The debugger can only support 4 hardware data breakpoints. If you use expressions (a + b), debugger uses emulation mode.

Data breakpoints only work on x86 processors, and can't catch kernel mode writes.

Data breakpoints can trigger operating system bugs. A data breakpoint set in one process might not be unset when the OS switches processes. This can cause other applications to crash. Windows 9x breaks often. Windows NT breaks less often. Reboot when it happens.

Memory Leaks

Memory Corruption

Optimized Code

Casting in the debugger

Modules Window

Debug Works, Release Doesn't

• Uninitialized variables
  • Often 0 used in debug builds
  • Unless /GZ switch is enabled
• Under/Overruns of memory
  • use debug heap (running in debugger on NT)
• Wrong calling convention (esp. GetProcAddress)
  • Use /GZ in compiler
• Optimizer unforgiving
• Overwriting locals more likely
  • Locals packed on stack
  • Locals reused

It works When I Don't use the Debugger

Timing Code

Add two watches

Watches are eval'd top to bottom. First one tells you the value of clock, second resets it. Each step will then update these values, and you can do simple profiling. Not good for assembly timing, because of debugger overhead.

Edit And Continue

Disassembly Tricks

Remote Debugging Made Easy

COM Debugging

Verify validity of COM object

Verify validity of a BSTR

Contact webmaster - Copyright © 2002 (2002)