4 ms·
When you're first working on a large chunk of unfamiliar code, stepping in gdb is an AMAZING way to learn how the code works. If this guy is advocating adding
by psranga 18y ago
When you're first working on a large chunk of unfamiliar code, stepping in gdb is an AMAZING way to learn how the code works.
If this guy is advocating adding prints to code, then his edit-compile-debug cycle must be very fast (i.e., smallish programs). On my large-scale project, it's much faster for me to restart the program with new breakpoints than compile and run again.
The latest gdb has checkpoints. That is a significant advantage over printf-based methods.
Of course, reasoning about programs is a very very effective tactic to solve bugs. If you write you code so that you can reason about it, you reduce the need for both printf's and debugs. As somebody pointed out above, this usually means writing short methods.
- larrywright 18y agoI'd agree with this (in spite of arguing against debuggers above). I was referring to my own development. In the case where you're handed someone else's spaghetti code and given the directive "fix this!", the fastest way to get up to speed on how things work is with a step-through debugger. That said, if you have the time I still think the best solution is to develop unit and functional tests (assuming none exist), and learning the code base that way.