|
|
There are naturally many other tricky details for us to
cover, but the framework for the discussion has been laid.
It is easy sailing from now on. Even so you may wish to
hammer out labs 7, 8 and 9 this week and next, and
perhaps strengthen your experience with gdb or ddd.
Here your lab TA should be able to provide good advice on
debugging practice.
Personally I still remember an earlier school of thought
which builds very small working programs of the essential
elements that illustrate the difficult parts, with the
support of print statements.
Only after the ideas are straight are they embedded into
the real program.
For example in Assignment 2 my Map started with M=10
and N=6. Then I entered about a dozen words and printed
out the 3 most frequent. Map traverse was used to call
print statements to show exactly what was in each entry.
Other prints showed what hash number was generated,
how conflicts were resolved and when extensions or
transitions to the next map were made.
These print statements may be preserved in the final
version, but put under the control of compile-time debug
flags (or better yet, command line parameters).
|
|
|
1
2
3
4
5
6
7
8
9
10
11
