Hello there! I''m just learning C++ after using just straight assembler for quite a while. And it''s got some nifty features I''ve never used. For instance the Debug mode? I''ve got it working in debug mode and I can output degug strings and it tells me all the dll''s loaded, etc... But otherthan that what is the difference in the actual outputted executable? It''s obviously slower...
The reason I''m asking is my game runs perfect in both modes exceot in release mode one of the blits doesn''t seem to work. I don''t get an error though, but I don''t get my blit either. Why should this sort of thing be affected by debug vs release mode? That has nothing to do with debugging yet it works in one but not the other?
I''ve seen people complain about this before too. Game features disappearing when they compile in release mode. So what''s with this?
Thanks,
Ben
__________________________
Mencken's Law:
"For every human problem, there is a neat, simple solution; and it's always wrong."
"Computers in the future may weigh no more than 1.5 tons."
- Popular Mechanics, forecasting the relentless march of science in 1949
C++ Debug vs Release
Guess what, you can debug in debug mode! Set break points and all those goodies, and still see the C/C++ code. Also, you can set a switch to initialize all variables to whatever value you wish...(this is set by default, to 0xCCCCCC I think).
Ever tried having your for loop breaking after exactly 2013 iterations? Really a nifty tool.
"Paranoia is the belief in a hidden order behind the visible." - Anonymous
Ever tried having your for loop breaking after exactly 2013 iterations? Really a nifty tool.
"Paranoia is the belief in a hidden order behind the visible." - Anonymous
Make sure you don''t rely on any debug-only good. In release the symbol _DEBUG is defined, so any code inside #ifdef _DEBUG #endif wont be included in a release build. For example, the assert macro expands to nothing in release, so don''t do something like this:
Becase in realease it''ll be as if you wrote:
Also, in debug arrays tend to have extra info added to them so off-by-1 array indexes don''t cause a crash.
Another possible problem (not very likely, but it has happened to me a couple of times) is a optimisation error. If you''ve got your optimisations set to max speed, try changing them to default and see if the problem goes away.
void foo(){ assert(some_function_that_must_execute); // ...}
Becase in realease it''ll be as if you wrote:
void foo(){ // ...}
Also, in debug arrays tend to have extra info added to them so off-by-1 array indexes don''t cause a crash.
Another possible problem (not very likely, but it has happened to me a couple of times) is a optimisation error. If you''ve got your optimisations set to max speed, try changing them to default and see if the problem goes away.
Actually _DEBUG is defined only in the debug version, not in release .
"Paranoia is the belief in a hidden order behind the visible." - Anonymous
"Paranoia is the belief in a hidden order behind the visible." - Anonymous
Oops, I switch it from NDEBUG because I thought that might just be MSVC (and it's better to check if it is debug, than check if it's not not debug) but I forgot to change that part.
Edited by - Wilka on September 2, 2000 4:25:20 PM
Edited by - Wilka on September 2, 2000 4:25:20 PM
Yeah they about sum it up :]
The main thing for Game Development would probally be that you can output variables and stuff with the trace() command and it wont slow down a bit at all because the debugger buffers it!
As for:
#ifdef
//stuff in the middle
##endif
...you can take and put stuff in the game like backdoors, command console codes, and stuff like that, the kind of things you don''t want the players to have in it
The main thing for Game Development would probally be that you can output variables and stuff with the trace() command and it wont slow down a bit at all because the debugger buffers it!
As for:
#ifdef
//stuff in the middle
##endif
...you can take and put stuff in the game like backdoors, command console codes, and stuff like that, the kind of things you don''t want the players to have in it
AH HUH!!! I figured it out. So how many of you have ever spent many long hours working on a problem only to realize it was something really simple....
You wanna know why my blit wasn''t working in release mode? Cause the bitmap is was loading to blit with was in the debug directory of the project! Simple move.. and it worked!
Thanks anyhow! I''m learning quickly...
See ya,
Ben
You wanna know why my blit wasn''t working in release mode? Cause the bitmap is was loading to blit with was in the debug directory of the project! Simple move.. and it worked!
Thanks anyhow! I''m learning quickly...
See ya,
Ben
Ok, here''s one more VERY IMPORTANT difference in Debug and Release mode. Similar to the Array and Memory allocation off-by-one situation.
The C++ language says nothing about the contents of uninitialized variables, arrays, or dynamically allocated memory (except when the variable is static (and perhaps global - not sure) - then it is always guaranteed to be initialized to all zeros).
C++ compilers follow these rules, and therefore waste no additional overhead initializing memory allocation in release mode (which mean if the OS zeros the memory like Windows NT it''ll be zero, UNLESS it''s being reused from a previous allocation of the heap manager ... but in Windows 95/98 it may or may not be zeros). In debug mode however nearly all compilers set all bytes or words of memory to some sentinel value (like 0xC0 or something ... which is NEVER zero). This can be an issue if you are using uninitialized memory, and you are checking for a zero value (which will often be there in release, but not in debug).
The C++ language says nothing about the contents of uninitialized variables, arrays, or dynamically allocated memory (except when the variable is static (and perhaps global - not sure) - then it is always guaranteed to be initialized to all zeros).
C++ compilers follow these rules, and therefore waste no additional overhead initializing memory allocation in release mode (which mean if the OS zeros the memory like Windows NT it''ll be zero, UNLESS it''s being reused from a previous allocation of the heap manager ... but in Windows 95/98 it may or may not be zeros). In debug mode however nearly all compilers set all bytes or words of memory to some sentinel value (like 0xC0 or something ... which is NEVER zero). This can be an issue if you are using uninitialized memory, and you are checking for a zero value (which will often be there in release, but not in debug).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement