|
|
|
|
|
|
by willcipriano
1616 days ago
|
|
|
> If you already knew which if statement to look at, it's irrelevant whether you use a debugger or printf(). That's exactly when it matters, when you don't know where the problem is. You have a big ball of spaghetti business logic and a customer object that is passing through it. At some point the customers total balance is screwed up. You can: - Read a lot of code and guess where that happens and set a printf or two, if you find it great, if not read more and set more printf's - Set a watcher on the customers total, and review the logic each place it is modified and ensure it is correct before moving on The first way you have to build the project over and over again, and you might miss something. The second way guarantees you find the problem eventually, and you only end up building a few times. If we have a project with a 5 minute build time, and a really thorny problem this can be a massive difference. That isn't to mention the value of doing this in concert with the creation of a unit test that recreates the bug to further reduce the bugfix feedback loop. |
|
|
Now the question is, how do you tell from the trace that the total is wrong? If you can write a function to check it in the debugger, you probably can -- with roughly the same effort -- write an assert() or (asserts) in the program where that variable is modified, and that'll ensure you'll be immediately notified the next time it goes wrong even before anyone notices let alone has time to dig out a debugger. I'd say the value of creating asserts is up there with unit tests.
You can object that actually the problem is in the complicated business logic and is already gone by when the assert fires and the wrong value is finally assigned/updated to the variable, but that same problem would come up in a debugger too. At one point your debugger notices that whoops it's gone wrong, but you don't know how exactly how you got there? Like I said in another thread here, things like rr can really change debugging (allowing you to rewind time, sort of) when they become available to your platform & language, but until then, I just don't find very compelling arguments why inspecting bad state in business logic would be so much faster in a debugger than with printfs. I find debuggers useful mainly for some niche things (ok, which NULL or freed pointer did I dereference and segfault on?).
Now if you have to make an argument about performance, go ahead, but that's kind of orthogonal and it goes both ways. Some programs run too damn slow under a debugger, sometimes you have to make a separate build with debugging info and different build options (again possibly with a massive performance impact) and figure out how to use all that in conjunction with the target system that only has a few dozen megabytes of spare RAM.. if running a debugger requires none of that but builds are slow for you, go for it.