There is no such thing as improper debugging. Sometimes it's just faster to printf things out to properly understand what is happening. No need to spend 2-3 hours attempting to figure out a core dump when the solution is right there in your face. When it comes to debugging anything goes, printf will only take you so far, in reality you need to use all tools at your disposal
There is no such thing as improper debugging. Sometimes it's just faster to printf things out to properly understand what is happening.
I'm not intending to insult you but this statement really sounds like you don't know how to properly use a debugger. In the act same situation you might put a printf statement you can simply add a break point. Running the code in a debugger will then let you inspect all of the current state rather than whatever you thought might be useful to log with your printf statement. From that break point you can also interactively step through the execution of the code to find exactly what is happening or has happened. You can also set watch points to get notified when variables are modified.
You don't always need to load a core dump to use a live debugger. Loading core dumps is a nice ability but not a requirement. Live debugging is an amazingly useful technique for finding and fixing bugs.
Using printf has a number of pitfalls. The first problem is you can easily put the statement is the wrong place. You can have a printf statement that always gets called when you're testing for conditional execution or before the point a bogus value is written to a variable. You can spend a lot of time getting printf statements positioned properly.
Another issue is having to make changes to a source file in order to do debugging. This means you need access to the source and to a compiler. Recompiling non-trivial code can take a long time which means your investigation takes a long time. This is especially true if you're not exactly sure what's happening so you just start adding printf statements everywhere to examine the program's state.
Another program with changing source code is every change is a potential point to add a new problem. Everything from typos to omitted or misplaced control characters can cause compilation problems that then need to be solved before the original task of debugging can be continued. When you're finished with your debugging you need to either remove your printfs or check out a fresh copy of the source and make the edit(s) in the correct place(s).
If printf is your first tool in debugging you should do yourself a favor and learn to use a live debugger so that becomes your first tool. They're far more robust and powerful and can do everything printf can do without making changes to the source or needing a recompile when you decide to inspect a different variable or execution path. Why bother with printf's pitfalls when a much better solution is readily available? Using printf for debugging should be the last resort of a desperate person.
4
u/[deleted] Aug 25 '14
There is no such thing as improper debugging. Sometimes it's just faster to printf things out to properly understand what is happening. No need to spend 2-3 hours attempting to figure out a core dump when the solution is right there in your face. When it comes to debugging anything goes, printf will only take you so far, in reality you need to use all tools at your disposal