On Tue, 30 Dec 2003 15:40:40 GMT, "Victor Bazarov"
<v.********@com Acast.net> wrote:
"Martijn Lievaart" <m@remove.this. part.rtij.nl> wrote... On Tue, 30 Dec 2003 03:21:05 -0800, arber wrote:
> Hi,
>
> I wrote a C++ program(Using VC 6.0). It's run well under debug
> environment.
> After i finished it and made a release version. The different results
> are outputed.
> Anybody have this experience? I guess that's because the optimized
> compiling in the release version. How can i do?????? :-(
> Really thanks for your help.
As one tip, look for asserts with side effects.
'nother tip: some compilers zero-initialise all variables in Debug
but not in Release. Initialise the necessary variables yourself.
Martijn and Victor's suggestions are good ones.
In my own experience, such differences have often resulted from
overrunning array boundaries. In debug mode, there are several "buffer"
bytes tacked on to the end of any memory block, which you can write to
and read from without breaking anything else (such as the variable
defined just before or just after the block in question). In release
mode, of course, these buffers vanish, and what was formerly an
innocuous bug becomes catastrophic. Debugging environments should let
you know when you have written into these buffers (although my
experience has been that they don't always), but they surely can't tell
if you are reading from them.
One other point of note. I recently worked on a project which involved
heavy amounts of floating point calculations. Running the same data
through the debug and release versions often gave results that varied by
1% or more. I stepped through the code in both situations (it's
possible, though not always good for your sanity, to enable debugging of
release builds) and saw that multiplying the same numbers did not give
the same results. Setting the "improved floating point consistency"
option (in MSVC7.1, don't know what other compilers might have such a
setting) brought them much closer together with no noticeable change in
speed.
--
Greg Schmidt (gr***@trawna.c om)
Trawna Publications (
http://www.trawna.com/)
