For example:
- When debugging multi-threaded code, you can test interlace events by manually pausing executing of certain threads at certain points. I've used this many times to manually reproduce a rare race condition.
- Tweaking a conditional breakpoint at runtime can be easier than rewriting code and re-running.
- Visual Studio has "tracepoints" which are like inserting a puts/printf statement in the code, but allows you to output things you might not easily want to write code to do like the current callstack or function name, e.g. "Print the callstack when I enter this function every 100 times I enter it"
- Poking around in memory can reveal things you wouldn't have thought to output, or is invisible in output, e.g. discovering a BOM in one string and not the other and having that be the cause of a comparison failure or a different path through the code than you think it should be taking.
- Trying to understand control flow when exceptions might be thrown or assertions might be triggered just isn't as easy with puts/print. You're likely to make a bad assumption. Understanding exceptions and how to make your application easy to debug is definitely a skill that begins at coding, not opening the debugger.
If you don't think you "have to learn a debugger" you're missing out on a lot of opportunities to be better at finding bugs.
GDB is not innate.
Therefore GDB has to be learnt.
---
I don't understand your lack of understanding :)
EDIT:
Addendum: Symbolic debuggers like GDB are non-trivial to pick up, is that what you're arguing against?
Are we supposed to believe that some people can understand unix, c++ etc but cannot learn/keep a cheatsheet handy so they can employ the ~10 commands needed to use gdb fruitfully?
There is not much to learn if you have used any debugger in the past.