Debugging in Visual C++

I am having a hard time debugging in Visual C++. Most of the time, the element I want to watch is optimized away. I see something happening, but I am unable to figure out why, because the debugging tools do not offer anything. Not the values of the variables, exception details etc..

I am essentially a C# programmer who is also working on a C++ project. This works out fine most of the time, except when I need to debug the program.

Are there any best practices to debug production code? Are there any tools that are more suited than Visual Studio? I want to be more productive then what I am at this time in C++, but the debug thing is holding me back. Any hints, advice or information is welcome.
Debugging normally happens on debug builds, not release builds.

Figure out how to make debug builds if you want a useful debug experience.
In Visual Studio, you generally get the option of a "Release" build and a "Debug" build.

"Debug" build has no precise meaning, but it generally means that the compilation options are chosen to make it easier to debug with. For example, fewer optimisations.

So first, ensure you're building in "Debug".

If you already are, open up the options, find the optimisation level, and turn it down.
Compile your project in Debug mode, and run it in Debug mode ("Start Debugging").

Visual Studio has one of the better Windows based debuggers available, and with the IDE being free in the Community edition the debugger is free as well.
The 10 cent why: c++ is a compiled language and as such, it renders your code down to efficient machine language before it runs, not on the fly, allowing for global optimizations and many tricks that JIT cannot do. What that means is that the compiled code is very much not one to one for the written code, so its not possible to tie the executing program back to the code you wrote, when you have optimized it. In debug compiles, the code is compiled more one to one mode (inefficient) with hooks in it so that the debugger can track where you are and what happened and report it back to you. Debug code is often a hefty multiplier slower than release code so do not forget to put it back to release when it works.
Debug code is often a hefty multiplier slower than release code so do not forget to put it back to release when it works.


Or as one of my former employers once managed, don't, and then ask me to improve performance when I start working there. I opened up the build script, changed the -O0 to -O1, took the rest of the week off.

I changed the -O1 to -O2 a month later when I needed a quiet week.
Topic archived. No new replies allowed.