What are your favorite debugging techniques in C++? [closed]

Answer 1

Assertions. When I'm writing code, if I spot any edge cases which I think might indicate trouble, I can drop in a line which will let me know in debug builds if such a thing is happening. For bonus points they have no performance effect on release builds so you can check semi-expensive things like eg. assert(someMap.find(someKey) != someMap.end());

Obviously they're not a replacement for checking real error conditions which you have to catch, but they're great for those fringe cases where you think "maybe I should check that" while you're writing the code.

Answer 2

In general, printf's. They allow for easy program slicing and don't require any tools other than an editor and compiler.

Answer 3

When writing code, consider how you're going to be putting breakpoints in there later. This particularly means not overdoing nested function calls - foo(bar(baz)) - and the same for field/method chains - foo().bar().baz(). In general, unless expressions are trivial, it is often worth it to put them on separate lines and assign them to variables, even if the values are only used once - you can then easily step through each, set breakpoint precisely where you want, and you'll have the values around in the watch window. When compiling with optimizations, any such variables will likely be optimized away, especially if you use the const reference trick rather than relying on RVO to kick in.

Answer 4

I use the gdb command commands to create "printf" statements on the fly. Just make sure the last command is continue.

#assume two breakpoints, 1 and 2
commands 1
  silent
  echo calling baz\n
  set $print_foobar=1
  continue
end

commands 2
silent
  echo calling foobar\n
  if $print_foobar
    set $print_foobar=0
    backtrace
  end
  continue
end

I've recently fallen in love with this technique as it lets me create printf() statement for code that is already running. Plus GDB scripting though limited lets you do quite a bit when deciding what to print. I've yet to find a situation where a commands section wasn't as good or better than a printf().

Answer 5

If my program is too big I logically separate problem part and debug it independently. It gives an opportunity for code to be more modular also

Answer 6

Tracing through, modifying variables in memory to hit some obscure branch of code. Rarely edit and continue, for some reason I can't quite trust it to keep sane state, so full runs after a change.

When impossible to trace (gdb on windows is way too slow for example, hitting a breakpoint takes 30 seconds each time) then printf. Junk code and throws off timing in case of multithreading bugs, but sometimes it is the only way.

Disassembler debuggers when having to debug release builds without debug information (Olydbg is nice when it works).

Proper logging is nice when it is available, takes effort to setup and use, but very valuable when needed.

Sending stacktraces of crashes home is even nicer.

Asserts spreaded around where needed.

Minidumps for crashes on users machines. (Reproducible crashes are the best. If bugs can't be relied to show up on time then what can?)