Actually, this one isn't a problem. No, really, it isn't a problem. For the computer, that is. For humans, it is a pain!
Y'see, when you turn on the maximize optimizations the optimizer does all kinds of great stuff that is just really hard to describe to the debugger. It can remove variables, reorder lines, move computations and sometimes even make it look as though your 'this' pointer is somebody else's this pointer. All of this is because the optimizer can (and does) do neat stuff.
In general, debugging optimized code means that you'll spend a fair amount of time in 'mixed view' so you can see the disassembly and the source code. In practice, VS2008 does a better job of keeping the debugger informed about what the optimizer has done, but only up to a point.
When I want most of my code optimized and just a portion in 'debugger friendly mode' I surround my code with #pragma optimize("", off) to temporarily turn off most optimizations and #pragma optimize("", on) to return to the defaults.
Rock on.
Ned
http://debuggingwindows.com/blog
Y'see, when you turn on the maximize optimizations the optimizer does all kinds of great stuff that is just really hard to describe to the debugger. It can remove variables, reorder lines, move computations and sometimes even make it look as though your 'this' pointer is somebody else's this pointer. All of this is because the optimizer can (and does) do neat stuff.
In general, debugging optimized code means that you'll spend a fair amount of time in 'mixed view' so you can see the disassembly and the source code. In practice, VS2008 does a better job of keeping the debugger informed about what the optimizer has done, but only up to a point.
When I want most of my code optimized and just a portion in 'debugger friendly mode' I surround my code with #pragma optimize("", off) to temporarily turn off most optimizations and #pragma optimize("", on) to return to the defaults.
Rock on.
Ned
http://debuggingwindows.com/blog
