Debuging results differs from running
i´m using Visual C++ 6.0 and in my project i saw a strange situation. when i run it with ctrl-f5 it show me (graficaly) one thing and when i run it with f5 or ctrl f10 it shows me things totaly diferent. actually the ctrl-f5 is the result that i want, but its very hard to debug it because of this. i´m using tokamak physics lib in my project and OpenGl but i thought it doesnt matter. Any suggestions????
Upgrade to VS.Net. This will become much less likely, IME.
It''s also possible that you''re doing something illegal, that isn''t flagged by the compiler. Like using a variable that wasn''t assigned.
Try raising your compiler warning level. Maybe he will spot your error.
Cédric
It''s also possible that you''re doing something illegal, that isn''t flagged by the compiler. Like using a variable that wasn''t assigned.
Try raising your compiler warning level. Maybe he will spot your error.
Cédric
I dont use the debugger much, but one time i did use it, i had a similar problem.
It turned out it was because i was making a graphics demo (particle engine to be exact), and when i was using the debugger, I would get huge bursts of particles, and then nothing, then huge bursts... But when i executed the program normally, it was a smothe flow of particles (which was what i wanted)
The problem was the time-based movement of the particles. I had a function called getTime(), and my program was using the difference in time between the current frame and the last frame. When running normally, this difference would be about 20 milliseconds, but in the debugger, it was between 200 - 20000 milliseconds (up to 20 seconds , when i was stepping through the code slowly). needless to say, this was the cause of the strange behavior.
HTH
It turned out it was because i was making a graphics demo (particle engine to be exact), and when i was using the debugger, I would get huge bursts of particles, and then nothing, then huge bursts... But when i executed the program normally, it was a smothe flow of particles (which was what i wanted)
The problem was the time-based movement of the particles. I had a function called getTime(), and my program was using the difference in time between the current frame and the last frame. When running normally, this difference would be about 20 milliseconds, but in the debugger, it was between 200 - 20000 milliseconds (up to 20 seconds , when i was stepping through the code slowly). needless to say, this was the cause of the strange behavior.
HTH
When you run debug mode, I believe Visual C++ sets some (possibly all?) of the uninitialized variables to seme default values. This is isn''t the case for non-debug version. This is quite often the difference between the two builds in my experience.
Hello Agemaniac,
As CrazyMike says, I can verfiy that in debug mode it will initial global pointers to a value of 0xcdcdcdcd or something like that it been a while since I did any M$ compiling, which if you do any checking of pointer a vaild by doing this if(pointer) instead of if(pointer==NULL) you will get funny problems.
Why they do this I not sure, they must have a reason.
Lord Bart
As CrazyMike says, I can verfiy that in debug mode it will initial global pointers to a value of 0xcdcdcdcd or something like that it been a while since I did any M$ compiling, which if you do any checking of pointer a vaild by doing this if(pointer) instead of if(pointer==NULL) you will get funny problems.
Why they do this I not sure, they must have a reason.
Lord Bart
quote:Original post by Lord BartUh, could you explain the difference between the two? I always thought that they were equivalent.
if(pointer) instead of if(pointer==NULL) you will get funny problems.
quote:Original post by Lord Bart
Hello Agemaniac,
As CrazyMike says, I can verfiy that in debug mode it will initial global pointers to a value of 0xcdcdcdcd or something like that it been a while since I did any M$ compiling, which if you do any checking of pointer a vaild by doing this if(pointer) instead of if(pointer==NULL) you will get funny problems.
Why they do this I not sure, they must have a reason.
Lord Bart
By setting all uninitialized data to 0xCD you''ll have a much easier time finding out what''s uninitialized when debugging.
And I beleive that running in debug mode might use different PATHs.
quote:Original post by AndreTheGiant
I dont use the debugger much, but one time i did use it, i had a similar problem.
It turned out it was because i was making a graphics demo (particle engine to be exact), and when i was using the debugger, I would get huge bursts of particles, and then nothing, then huge bursts... But when i executed the program normally, it was a smothe flow of particles (which was what i wanted)
The problem was the time-based movement of the particles. I had a function called getTime(), and my program was using the difference in time between the current frame and the last frame. When running normally, this difference would be about 20 milliseconds, but in the debugger, it was between 200 - 20000 milliseconds (up to 20 seconds , when i was stepping through the code slowly). needless to say, this was the cause of the strange behavior.
HTH
If you use "virtual time", this problem goes away.
just a comment..if in debug mode it sets all uninitialized varible and in runnning mode it does not how can this affect the simulation. If it is not initialized in running i may got wrong results, but i get right results. then i thought all the variables are ok...i dont know. is there a way in MSC++ 6.0 to disable this kind of initialization in debug mode?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement