>And please don't debug code at one level and then crank up the>optimization for a production compile. Your ship code should always>be exactly what you've debugged.

I disagree.

Your ship code should always be what you've tested.

You debug to diagnose bugs - not to detect them. Probably 99% of
errors in new code are simple logic errors. Around 99% of those behave
identically whether the optimiser is on or off.

So you automate your unit tests, write them according to what you
expect from the code (as opposed to what it delivers) and run them
religiously on both your debug and release versions. When both fail
identically (as they normally do), you usually have a good idea what's
wrong anyway, but if you don't then that's the time for the debugger.

If you "test" your code by running the debugger, odds are you see
nothing different to what you had in mind when you wrote the code. Of
course you can catch a few bugs this way, but it's very unproductive.
It takes at least as long as writing and running a few unit tests, but
you don't get anything repeatable at the end. You have no guarantee
that the same or similar bugs won't get through undetected in the
future.

With unit tests, you even get that immediately useful hint when the
debug and release versions behave differently. 99.9% of the time
(unless you're using a really crappy compiler) this tells you that
someone's doing something stupid with a pointer.