Ok, I use MSVC++ 6.0 . I finished writing a game using the Dos Console App project (ascii graphics, nothing very complex). I tested it as much as I could, running the exe it made in my debug folder of the project. I then fired up the complier again, and recompiled in release-mode so I can have a smaller exe without the un-needed debugging information, just incase I wanted to send a copy of my program to a friend or whatnot. However, after running the new release-mode created exe, the program did NOT run like it had when I compiled in debug-mode. Very hard to describe just how wacky my program acted. I ended up loading up Dev-C++ and building the project without debugging info to get my "release" program. Though I disliked having to load up a FREE compiler to do this, it got the job done. I suspect this wouldn''t happen when I''m past the dos console. Anyways, I''m not looking for a solution to my problem, and I''m not asking what I did wrong (which is why I left out details). My question is what kind of things are changed from the debug version to the release version of a console app beyond stripping the debug info? I''ve never seen any difference in performance before, which is why this is startling, and without the debug info, I cant go through the program and see what it''s doing different. Perhaps if I know what kind of changes happen, I can avoid this problem in the future

In MSVC, the differences are fairly major. There''s a whole lot of sanity-checking code that is left out in release mode. One of the major differences is that debug fills memory areas with key values so you can hope to tell if you''re accessing an uninitialized variable, or if you''ve overflowed your memory area. None of that filling or checking is in the Release. _DEBUG isn''t defined, so if you''re doing anything special with that it won''t be in there. Other than that, it''s all optimization I believe (unless there''s something I''m forgetting).

It''s hard to tell what behavior is giving you a problem--it just worked with a different kind of efficiency? Or are you getting crashes? If you really, really need to debug a crash that only happens in Release mode, you can turn on the program database in your release mode build and then use the debugger. However, be warned--you are almost guaranteed that none of your watch variables or anything will make sense from the beginning of the function till the end. The compiler is free to do any number of zany things with stack pointers and such to optimize your code, which makes things very hard to track.

Wel, I dont crash. I have a matrix I''m using to simulate a Connect 4 game. User has a choice of 7 columns to drop their pieces in, and it drops the chip into the lowest available row of that column. Couldn''t work better in debug mode, but release... first chip that drops all of a sudden appears in the first row of every column, after, you cant see other chips that drop, it''s just really bizzare behavior

Some of those release mode only optimizations will impact any floating point math that you might be doing. You sometimes get more or less precision in floating point calculations when you switch modes. This happens because release mode will tend to keep floats in registers and debug tends to keep them in memory.

If you are using == (for example) on floats, that could break your code in one mode but not the other. So never use == on floats.

Yeah, happened to me all the time. That is why I like Borland and GCC, the onlly difference between debug and release mode is debug information period! You can even turn on optimisations.

Borland also has a nice tool call CodeGuard which let you know about pointer accesses and memory leak. Very neat and much more usefull than VC++ padding.