visual's built in, and I also am willing to add print (or file write) statements to see what went wrong when it is running, esp. when you can't reproduce the error easily and need to run the code for a 'while' before it pops up.
I've used Visual Studio's debugger because I find its GUI easy to use (setting break points, variable watch list, setting different values at runtime).
Would like to use gdb, but I find it way too tedious to use. Plus, gdb has crashed when I've tried to set particular breakpoints. I'm most certainly not doing it efficiently, but I also think it shouldn't crash. Wonder if anyone has a particular guide or technique.
Good debugging skills vastly simplify troubleshooting a program.
Important things to know:
- Best place to set a breakpoint for each particular problem.
- How to use conditional breakpoints
- How to set a memory access breakpoint
Completely agree that debuggers are powerful and using them well is a skill, but I never really enjoy using them. I guess maybe a better question is, do people think that they use a debugger less frequently than they'd optimally like to?
I use gdb through its CLI. It takes some learning to become competent with it, but it's actually not that bad of a user experience IMO. I mostly learned by skimming through reading the GNU project's manuals. And yes, it's significantly more pleasant than figuring out what went wrong without a debugger.
There's a project called rr whose purpose is to record the execution of programs for later bi-directional (!) playback and analysis in gdb. I've used it a few times, and the rest of you might find it useful. https://rr-project.org/
Personally, I kind of enjoy debugging code. It can be made fun if you think of it like a puzzle that you have to solve. Sometimes it can get pretty hairy and it's frustrating when you can't figure something out, but when you finally do you get that rush of dopamine and it's great.