hi everyone,

we've had a couple of challenging hws, so you'll be happy to know the next
homework is relatively straightforward (and has no programming component).

Chapter 5 & 6 are about debugging and testing.

POP has extensive comments on debugging, so i'll just point
out the ones i think are especially important.

 -  LEARN TO USE A DEBUGGER!  

    at the very least, you should be able to set break-points (conditionally), 
    step through code, print the values of variables, and move up and down the 
    call stack.

    surprisingly, even though your program may execute millions (or billions)
    of instructions, before it exhibits problems, it's usually not too hard
    to actually execute it in a debugger to get to the point where it crashes.

    very often, if you just look at a printout of the code, it'll do what you
    think it does - running a program in the debugger shows you what the 
    program actually does.
 
 - use tools to help you identify problems:

   o compilers have warning flags (gcc uses -Wall) which identify things which
     syntactically correct, but are signs of potential problems: unused 
     variables, functions not returning values, use of = in a conditional 
     check in C/C++, etc.  always compile with these flags on, and be sure
     you've understood why warnings are generated.  (they are not always a sign
     of problems, e.g., you may not use a variable you're assigning to if
     you're just using it to test a function, but be sure to understand 
     the warning.)

  o tricky memory problems (segfaults, leaks, data getting corrupted) are best 
    debugged by using tools specifically targetting these.  on unix, you can
    use dmalloc (www.dmalloc.com) which is basically a library which replaces
    malloc and free - you link against the dmalloc library, and your calls to
    malloc and free are implemented by the versions in the dmalloc library;
    these versions do things like keep track of where memory is allocated,
    whether unallocated memory is being read/written to, etc.  

 - don't make the same mistake twice: if you fix a bug somewhere, ask yourself
   where else you made the same mistake.

TESTING: POPs remarks on testing are fairly comprehensive.  you may find the 
concept of extreme programming quite interesting 
(http://www.extremeprogramming.org/) one key idea here is that test is 
as important as actual implememtation, and every class/function/package should 
code a set of test routines FIRST!

it's actually not that difficult to write test routines first.  they 
don't have to be comprehensive right from the start, but if you put them off 
till the day they are "complete", chances are you'll never put them there 
in the first place.

cheers,
adnan