I've compiled each file in my project separately.. No Errors/warningsOriginally Posted by matsp
I've compiled each file in my project separately.. No Errors/warnings
I press CNTRL+F10 to run to cursor... then press F10 to make sure i debug/step on every single line thereafter... In this, my function gets skipped... Even if i try running inside that function (CNTRL+F10), the code never gets there....
F10 is step over. It executes any functions without stepping into them.
To step in, use F11.
i know that Elysia... I had to delete all project files and created a new project with new names... Add all my files and now works fine...
May have to do with the changes i made (from Debug to Release mode), don't know really
In Release, debugging can be somewhat more difficult because the compiler can inline and remove code (optimize), thus it may be seen as stepping over something it shouldn't or jump around erratically and other things. This is normal.
Indeed - the compiler will re-arrange the code A LOT when optimizing in release-mode, and setting a breakpoint in a function that is inlined will often lead to the breakpoint being skipped. It may also move variable assignments around in relation to functions or if/for/while statements (you have a = 1 before a statement, but the compiler decides that you are not using a until after the statement, so let's move it down a bit). Variable displaying in optimized code is also often flawed, since variable content may skip from one register to another, and sometimes be stored in memory and at other times in a register. The debugger can often be confused by this sort of variable "variability". Another side-effect of optimization may be that variables completely disappear, and that a variable used to count up from 0 to 999 becomes a count down from 999 to 0 because to the logic of the code, all that matters is that it counts 1000 steps, not whether it goes up or down - and counting down saves one instruction compared to counting up - which matters to the compiler. But this also means that your loop variable may not appear in the way you expect it.
In summary, the compiler may do anything it likes that doesn't change the outcome of the code itself. This makes it very tricky to debug the optimized code - I find it easier to follow the assembler code rather than the source code when debugging optimized code - but that probably comes from a long experience in debugging assembler code.
If it is possible to reproduce the bug with debug mode, then use that fore debugging. If you can only reproduce the bug in release mode, then you have to struggle with it.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
The idea is to do the debugging in debug mode. The debugger is completely unreliable in release mode and as others have said it will skip breakpoints and refuse to show data to you in watches.
However I've not had a problem debugging console apps with VS 2003 or 2005. Not sure what the problem is here but I have no issues. You can output to the screen just fine and click on your app in the task bar and it will repaint itself. I debug console apps all the time at work and rarely need to use my second monitor. You could remote debug the app but then that is overkill.
