Lab #9
Debug, Compile, and Run a C++ Program

What We're Gonna Do:

In this lab we'll get away from VisualWorks for a while and try playing with C++. Hopefully, after doing this lab you'll have a better feel for

The procedure is pretty simple. Save the buggy C++ source code that you find at this link as plain text. Call it lab9.cc just so that we can refer to it by that name throughout this document. Then open up another window on your workstation and log into one of the acme machines. If you don't know all the details about this, ask your neighbors or the UA. The C++ compiler in the Baird cluster is broken, so we need to use the one on acme. It's suggested that you edit the file on your workstation, and just run the compiler on acme. That way you keep the load on acme lower and make editting your file faster.

Debugging the program

First thing you should do is read over the whole program. Figure out what it's trying to do. Look at the class declarations. Look at the class constructors and other methods. Look at the main() function. Spent enough time (about 5 to 15 minutes) just looking and building a picture of what the program does in your mind. It might be kind of familiar.

Now what you have to do is grab a sheet of paper. Put you name and section on it -- you'll need to turn it in to your TA before you leave the lab. On this sheet of paper, draw the Coad and Nicola OOA/OOD diagram describing the classes in this program. Look at this diagram and see if you can spot some of the things wrong with this source code.

After you have spent the time looking and drawing, dig into the code. Try compiling it (see below). If it doesn't work, fix what you think is wrong with it, and try again. Repeat. There are a number of debugging techniques that one can learn and derive along the way, but this isn't really the time or place to go into that.

This program has a number of errors of different flavors. Some of the errors are syntactic, and the program won't compile until you fix them. Others are logical errors; the program will compile, but it might not run properly. The last type of errors are errors is meaning; the program compiles and runs, but the output is in some ways not what you mean it to be. Find all of these errors, and keep hunting until the program runs to your satisfaction.

How to Compile and Run

To compile the program source code into something you can execute on the machine, you will use the GNU C++ compiler. It is generally called g++ and should be in your default path. It will generate an executable called a.out by default. To run it, simply type the name of the executable and hit return. To make the executable a bit easier to identify, you can pass an alternate name to the compiler. If you called the source code lab9.cc like we suggested, then the following will compile and execute the program: 
       g++ -o lab9 lab9.cc
       lab9

If you did that and had the compiler print a whole bunch of lines on your screen, then the program still has compile-time errors in it. Try to interpret the error messages, edit the source, and try again.

What you should turn in

You will turn in the Coad and Nicola diagram to your TA before you leave the lab. Don't forget, since this is worth buku points. You'll also save the output of your most recent version of the program in a file. Do this by entering something like: 
       lab9 > lab9.out

Mail the output of your program and your debugged source code to your TA:

(1:30-3)
cat lab9.out lab9.cc | mail -s "lab 9 - YOUR NAME" joita@cc.gatech.edu
OR (3-4:30)
cat lab9.out lab9.cc | mail -s "lab 9 - YOUR NAME" jyan@cc.gatech.edu
OR (4:30-6)
cat lab9.out lab9.cc | mail -s "lab 9 - YOUR NAME" smk@cc.gatech.edu