( Latest Revision: 04/03/2006 )

Lists: Implementing a Circular List


PRELIMINARIES:

Before starting this assignment it is imperative that you be familiar with chapter 4 of Carrano, including the section entitled "Variations of the Linked List." You also need to read the directions and examples here: http://www.cs.csustan.edu/~john/Classes/General_Info/progAsgRules/


THE ASSIGNMENT:

A circular linked list is a linked list in which the last element points back to the first element, instead of having a NULL pointer. You can get a lot of ideas on how to write the code for the new circular list class by looking at the "regular" linked list implementation code: ListP.h and ListP.cpp. Also you should read pages 209-210 of Carrano for more help. You must be careful to understand where and how the new "cListP" code must be different from the "ListP" code.


THE DRIVER:

Before you implement the new list class, you must write a simple driver program. The purpose of the driver is to process an arbitrary sequence of commands -- commands to perform operations on a list of strings.

The driver must: If we take a closer look at the job of the driver, we see it must execute a "command loop." In each pass through the loop, the program reads a one-line command from standard input, interprets the meaning of the command, echos the command to the standard output, executes the actions required by the command, and tells the results of the command. (The print command mostly just prints and does little additional "telling.")

The command loop must be written so that when it receives the stop command it prints a goodbye message and then exits.

It should not be a problem to develop the driver before the new list class is finished. For example, you can just put stub code in the functions of cListP.cpp and then test run the driver. When the driver executes, it will call the stub functions in cListP.cpp. Alternatively, you can make a minor modification in a "#include" directive in the driver, re-compile, and then test the driver using the "ListP" implementation of the list class. When programs are written in a modular fashion, this kind of thing is very easy to do. It's like plugging your headphones into one CD player, and then another -- pretty simple and easy to do.

I suggest you implement the "print" command completely within the driver. Make it a function inside the driver that uses the ListRetrieve function of the list class to retrieve and print each element of the list.


DRIVER INPUT AND OUTPUT:

The program must read all its input from standard input, and write all its output to standard output. (Naturally it will be convenient if you prepare files of input in advance and use unix redirection to allow the program to read its input from a file instead of the keyboard.)

The document sample.in is an example of the type of input the driver must process. This file: sample.out shows the corresponding output.

All inputs are simple commands that tell the driver to perform operations on the list. There is a stop command that tells the program when to quit.

The sample input set is not intended to test the program exhaustively. You need to do part of the work of designing and making the test inputs. Figure out what data boundaries and what average data examples should be tested for this program. When you make your test script, run tests on files with the appropriate content.


IMPLEMENTING THE NEW LIST CLASS:

You must create a new list class similar to the "ListP" singly-linked version of the list class we studied in chapter four of the Carrano text book. You must start with copies of the cListP.h and cListP.cpp files in this directory and fill in the missing function bodies in cListP.cpp as required to make the list class operational.

You must write the function bodies so that the functions are implemented exactly as specified by the function prototypes and the the function header comments in cListP.h.

Also, you must make sure the operations are adequately efficient. The work done by PtrTo, ~listClass, and Print should be bounded by a constant times the number of elements in the list. There is no way to do better than that, and the code should not do worse than that.

ListRetrieve, ListInsert, and ListDelete will need to call PtrTo. Besides the work done by PtrTo, the rest of the work these functions do should be bounded by a constant.

The amount of work done by listClass, ListIsEmpty, and ListLength must be bounded by a constant.


COMPILING:

Assuming that your class implementation file is named cListP.cpp and the file containing your driver is named driver.cpp, you should compile the program like this:

g++ cListP.cpp driver.cpp

include cListP.h in cListP.cpp and driver.cpp. (Do not include cListP.cpp in driver.cpp or vice-versa.)


WHAT TO TURN IN:

You will turn in two sets of hardcopies and you will send two e-mail messages.

With regard to the e-mail please follow these rules: Here is a list of the things you have to turn in:
  1. On the morning of the first due date, turn in a hardcopy of your completed driver code.
  2. Send me an e-mail copy of your completed driver code before midnight on the first due date. Send it by e-mail with the subject line: CS2500,prog4.drv.

  3. On the morning of the second due date, turn in a hardcopy of your completed driver code, cListP.h file, and cListP.cpp file.
  4. Send the following items to me by e-mail before midnight on the second due date:

    Include all header and source files (all *.h files and *.cpp files) that are required to compile the program into an executable image -- everything I need to compile the program. Combine all the source files and the script into one shell archive file and e-mail me the archive file with the subject line: CS2500,prog4.fin.

Note that there are no spaces in the subject lines given. It is important that you do not insert any spaces. My e-mail address is: john@ishi.csustan.edu.


DUE DATES:

For the due dates, see the class schedule.