basicDebugging_Lect(2)
basicDebugging_Lect(2)
1 The Program
The program we will work with computes some basic statistics on plain text.
The Code
cout << "Enter some text, terminated by an empty line:" << endl;
string line;
getline (cin, line);
while (line != "" )
{
addText (line);
getline (cin, line);
}
return 0;
}
words.h
#include <string>
int getNumberOfWords();
int getNumberOfSentences();
int getNumberOfAlphabeticCharacters();
#endif
words.cpp
and defined in
#include "words.h"
#include <cstdlib>
#include <sstream>
int numWords;
string* words;
int getNumberOfWords()
{
return numWords;
}
int getNumberOfSentences()
{
int numSentences = 0;
for (int i = 0; i < numWords; ++i)
{
char lastChar = words[i][words[i].size()-1];
if (lastChar == '.' || lastChar = '?' || lastChar == '!' )
++numSentences;
}
return numSentences;
}
int getNumberOfAlphabeticCharacters()
{
int numChars = 0;
for (int i = 0; i < numWords; ++i)
{
for (int k = 0; k < words[i].size(); ++k)
{
char c = words[i][k];
if ((c >= 'A' && c <= 'Z' ) || (c >= 'a' && c <= 'z' ))
++numChars;
}
}
return numChars;
}
2 Debugging Output
Something’s Wrong
Let’s suppose that we have run this program and discovered that the values being printed for the
average word length are incorrect. Looking that relevant portion of the main routine:
We can see that there are two different functions that contribute to this average.
Once we see the output of these two lines, we can determine which function needs to be explored further.
cerr
For debugging output, we usually write to cerr (the standard error stream) rather than
to cout (the standard output stream).
• cerr normally appears on your screen/console, just like cout usually does.
o And if you have redirected cout to a file, cerr will still appear on your console
• Makes it easier to later hunt for the debugging output statements and remove them or comment
them out without accidentally removing the "real" outputs.
Refactoring
Sometimes we can make it easier to add debugging output by refactoring, rearranging the code slightly
in a way that should not affect what it does.
into
Once we determine which function if giving incorrect answers, we can add debugging output there
until we have tracked down the problem.
Tips:
• If you believe the problem lies in a particular variable, insert debugging output after every
statement that alters the value of that variable
• If there’s a lot of such statements, try doing a "binary search" by inserting debugging output
halfway through the chain of changes, then determining if things go wrong before or after that
location.
Tips (cont.)
• Loops can drown you in debugging data. But if you suspect that the problem occurs in a particular
iteration of the loop, limit your output.
o Suppose that you had a failure on input "This is very strange! Isn’t it?" and believed that the
problem actually occurred on the 4th word.
3 Desk Checking
Desk Checking
In desk checking, we draw a "picture" of the input data, then step through the code, line by line,
updating the picture as the data values change
• a.k.a walkthroughs
• paper-and-pencil debugging
• One of the fundamental approaches to debugging, but often under-utilized
3.1 Example:
Example of Desk-Checking
numWords: 3
int numSentences = 0; words: "Hello.", "What’s", "up?"
numSentences: 0
numWords: 3
words: "Hello.", "What’s", "up?"
for (int i = 0; i < numWords; ++i)
numSentences: 0
i: 0
numWords: 3
words: "Hello.", "What’s", "up?"
numSentences: 0
i: 0
lastChar: ’. ’
Here, for the first time, we had a variable change value instead of simply adding new variables with initial
values. If we were doing this with paper and pen, we would simply strike out the old value and write in the
new one.
Sometimes I do desk-checking with a text editor, in which case I would overwrrite the old value with
the new one.
Keep On Checkin’
A great deal depends on the goal we had in mind when we first started desk-checking.
Tips
• The example above was easy because the data was simple. There were no pointers. The only
compound data structures were short arrays.
• Once we start dealing with data containing pointers, my “data pictures” will start being real pictures
instead of text.
o A white board is good for this kind of desk checking, as it allows you to erase old lines and
draw new ones.
Tips (cont.)
• You walk through your code while managers or team members watch and ask questions
• Only if you convince them that your code/design is likely to work, are you allowed to move
forward and actually add it to the project.
• Often called structured walkthroughs