Why would I start a debug build without debugging?

Question

Is there any benefit in starting a debug build without debugging (as opposed to a release build without debugging)? And what do I miss when I debug a release build (as opposed to debugging a debug build)?

Answer 1

Starting a debug build without debugging can give you for example the following benefit: if a contrainer is indexed with an invalid index you'll get an assertion failed, in release mode you'll get undefined behavior. That's one thought. What you miss when debugging in release mode is that there is no correspondence between source lines and assembly code any more because the optimizer has run. So it's far more difficult to debug in release mode

Answer 2

Biggest advantages of debug builds (outside of the IDE):

• Assertions are enabled, as is other diagnostic code you may have compiled within debug-dependent prepocessor sections.
• Stack traces and variable watches are working properly, so you can have beta testers send you a crash dump and debug that in your IDE later.

Biggest disadvantages:

• Slow execution, higher memory consumption, bigger file size.
• Some bugs are not evident unless you compile everything with full optimization. That's because memory allocation is working differently in release builds.

Many companies distribute debug builds to alpha and beta testers and switch to release builds later.

Answer 3

I'll offer a recent experience that I can't explain -- sometimes when I run my application, I get unhandled exceptions when running in the IDE. The problem is, I know my exception is getting handled, and I also know that I'm not breaking on thrown exceptions (via CTRL-D, E). If I hit F5 several times, my error handler eventually catches the exception and deals with it properly.

The reason for this has eluded me for several weeks, so when I don't want the execution to get interrupted, I run outside of the IDE and simply attach to the process later if I need to.

If you really need to see the Debug output while running outside of the IDE and you're not using something like log4net to capture everything, you can use DebugView instead.

Answer 4

To add to Adrians answer and as a general point when talking about debug vs. release builds:

Here are some factors that influence your builds:

• You link against either the debug or the release runtime libs (/MD vs. /MDd)
• NDEBUG (release mode) or _DEBUG (debug mode) is #defined
• _SECURE_SCL (or some equivalent) is defined (or not)
• Compiler optimizations are enabled (to some degree)

A "debug build" normally comprises _DEBUG, _SECURE_SCL=1, /MDd and all compiler optimizations disabled. This results in the "safest", "most-checked" execution mode, but also should be the slowest version you can get for your executable. The speed and safeness factors should be completely independent of whether you run your program under a debuger or not! -- The debug build gives you a maximum safety and error catching net, completely independent of whether the program is attached to a debugger.

Next comes a non-optimized release build: That is, you have all the release mode settings (NDEBUG, _SECURE_SCL=0, etc.), but you disable all compiler optimizations. This is good for testing, since performance won't be bogged down too much and you can debug this allright. Again, the usefulness of this is independent of whether you run your program under a debugger.

Finally come full optimizations. (/Ox + full inlining + possibly whole prg optimization): While this is what you would like to ship for performance reasons, chances are that you do not have enough people in your company that are actually able to debug this. That is, given a crash dump, someone most likely needs some amount of asm knowledge and what a compiler outputs to make some sense of the crash dump (or even some random breakpoint, when actually running under the debugger). Again, the pros/cons for full opt are independent of starting/running the prg under a debugger.