COSC 072/503 Project 2

COSC 072: Computer Science II

Project 2
Spring 2010

Due: Wed, Mar 24 27 @ 10 PM
10 points

In lecture, we have started discussing abstract data types, self-referential template classes, and containers. For this project, you'll use a singly-linked list to implement a stack and a queue, and you'll use a doubly-linked list to implement a double-ended queue (deque, pronounced "deck"). Naturally, the classes for these containers must be able to hold any object, so you must implement them as template classes. Specifically, you will implement and use the Node<T> class to implement Stack<T> and Queue<T>, and you will implement and use the DLNode<T> class to implement Deque<T>. You can implement DLNode<T> directly, or you can use inheritance to derive it from Node<T>.

All of the classes must implement a default constructor, a copy constructor, an overloaded memberwise copy operator (operator=), a size method, an empty method, a clear method, and a destructor. (Not deconstructor! That's POMO. This is C++.) Methods should throw appropriate exceptions, such as bad_alloc and StackEmpty, QueueEmpty, or DequeEmpty. Use constant parameters and constant methods as appropriate.

It is imperative that you follow our design for the public interface. For Stack<T>, pop must remove and return the object from the top of the stack, push must add an object to the top of the stack, and top must return a reference to the object on the top of the stack. For Queue<T>, dequeue must remove and return the object from the front of the queue, enqueue must add an object to the end of the queue, and front must return a reference to the object at the front of the queue. For Deque<T>, removeFront and removeBack must remove the object from the front and back of the deque, respectively, insertFront and insertBack must add an object to the front and back of the deque, respectively, and front and back must return a reference to the object at the front and back of the deque, respectively.

Any method that dynamically allocates memory must throw bad_alloc. Any method that returns or removes objects must throw the appropriate exception when called for an empty container.

To grade your project, we will drop a main function into your directory and compile. main will test all aspects of all of your three classes. As a consequence, it is imperative that you test all of your methods thoroughly, preferably as you're developing them.

All class definitions and class methods must be documented with Doc comments. Doc comments for class definitions must include @author and @version tags. Doc comments for methods must include @param, @return, and @throws tags, as appropriate.

Getting Started

I'm sure at some point while doing p1 and wrestling with the Makefile you thought, "There's gotta be a better way to do this." And indeed, there is. I've written a more flexible Makefile, which you should be able to use for the rest of the semester (and perhaps for the rest of your life) with little modification. To get started, on seva, first create the p2 directory in $HOME:

seva% cd ~
seva% mkdir p2
seva% cd p2

Now copy the Makefile from my directory:

seva% cp ~maloofm/cosc072/Makefile ./

Groovy.

If you're coding on a Mac or a Windows machine, you may need to edit the Makefile and change the .cc extension to .cpp. Further instructions are in comments at the top of the Makefile and we'll discuss the Makefile magic and how it works in class.

Instructions for Electronic Submission: At the top of the file main.cc (or the file containing the main function), place the following header comment, with the appropriate substitutions:

/*
 * COSC 072 Project 2
 * Name: <your name>
 * ID: <GoCard ID>
 * E-mail: <e-mail address>
 * Instructor: Maloof
 * TA: <TA's name>
 *
 * In accordance with the class policies and Georgetown's Honor Code,
 * I certify that, with the exceptions of the class resources and those
 * items noted below, I have neither given nor received any assistance
 * on this project.
 */

If you need to include a message to your TA about your submission, then place the message in a file named README. Place the README file in the project's directory.

Assuming all of your code is in the subdirectory p2, directory, this directory and the submit program should be in the same directory:

seva% ls
p2/ submit.jar

To reduce the size of the zip file, before submitting, remove all object and executable files:

seva% cd p2
seva% make clean

If you need to include a message to your TA or me about your submission, then place the message in a file named README. Place the README file in the project's directory.

To move from the p2 directory to the parent directory, type

seva% cd ..

At this point, you should be above the p2 directory:

seva% ls
p2/ submit.jar

(Additional useful Unix commands)

When you are ready to submit, change the name of the directory to your netid, not mine. As an example, assuming your netid is maloofm, rename the directory p2 by typing

seva% mv p2 maloofm

Create a zip file of the directory and its contents by typing

seva% zip -r p2.zip maloofm/*

This command creates a zip file named p2.zip by recursively (-r) copying all of the files (*) from the directory maloofm/.

To submit the zip file type

seva% java -jar submit.jar -a p2 -f p2.zip

p2 is the name of the assignment (-a) and p2.zip is the file (-f) to be submitted for that assignment.

If the program submits the file successfully, you will receive a receipt by e-mail at the address <netid>@georgetown.edu.

Submit your project only once.

Once you've submitted your project, it is important to keep an electronic copy on a university machine (e.g., seva) that preserves the modification date and time. If we lose your project or the submission system breaks, then we will need to look at the modification date and time of your project to ensure that you submitted it before it was due.

You can also change the directory's name back to the original name. For example,

seva% mv maloofm p2

Note that changing the name of the directory does not change the dates of the files in the directory. You can also remove the zip file from your directory:

seva% rm p2.zip

The TA who will be grading your projects this semester is listed on the main page. You must submit your project before 10 PM on the due date.

Plan B

Submit is pretty reliable, but it is software. If you're running submit correctly and you see an error message labeled as SEVERE, then it's time to execute Plan B by using mail to submit your project.

To accomplish this, assuming the file you want to submit p2.zip, type at the seva prompt

seva% uuencode p2.zip p2.zip | mail cosc072@cush.georgetown.edu

Briefly, uuencode encodes the binary file p2.zip as an ASCII file that can be transmitted as mail. This form of the uuencode command pipes the ASCII-encoded file through standard input and into (|) the mail command.

When we receive you mail, we will save it to a file and use uudecode to translate the ASCII-encoded file back to the original binary file. Virtually all mail clients automatically encode binary files in this way.

Please don't use this account for communication. We don't check it regularly.