CS 342 Lab 4: Unbounded Stack Class

 

http://cs.wustl.edu/~levine/courses/cs342/labs/lab4/

Lab date: 15-17 February 2000
Due date: Sunday 20 February 2000 11:59 pm

Objective:

The bounded stack of Lab 3 has a severe limitation: a bounded stack cannot grow beyond its initial size. This limitation will be removed in Lab 4. You are to write an unbounded stack using a linked list, i.e., using dynamic memory allocation. The linked list implementation will be hidden as much as possible from the stack.

Note that changes only affect the stack representation and not the stack interface. You are to re-implement the methods that operate upon objects of class Stack.

Preparation:

  1. Review the header file for the Stack template class (Stack.h) that is part of the distribution for this lab. Do not vary from this specification.

  2. If necessary, review your CS101/CS241 notes to recall what a linked list is and how to implement it.

  3. Review the header file for the History template class (History.h) that is part of the distribution for this lab. For the most part, you don't need to be concerned with the details of the History template class. But, you need to understand the information that it presents.

Assignment:

Given a specification for a Stack class, write the methods and operators for that class. The class represents an ADT with operations such as push, pop, top. is_empty, and is_full. Use a simple singly linked list structure for the implementation.

Develop an implementation for a linked list using the specification of the Node class given in (Node.h). you can either keep this specification intact as an undisturbed file, or put it into your Stack.cc implementation file. Therefore, stack clients won't have access to the implementation at all.

In addition, use the History template class to check for memory leaks. To use it, your Node template class must be instrumented by deriving from History. This has already been done in Node.h

A test driver program is supplied (main.cc) but you must extend it to completely test your implementation. Your implementation must check for error conditions, such as attempting to pop off an empty stack or push on to a full stack, and failing to allocate dynamic memory. The distributed main.cc is almost the same as that of Lab 3 (with the exception of the explicit template instantiations, which you probably don't use), so you should be able to reuse your Lab 3 main.cc.

Special Note: Be sure that push, pop, and top check whether the stack is empty or full, as appropriate. They return 0 for success, or -1 if the stack was already full when attempting to push, or empty when attempting to pop or top.

NOTE your definition (in Stack.cc) of the Stack (size_t) constructor must omit the default parameter. The default parameter is only used in the method declaration, in Stack.h. And, the definition should omit the parameter name (but not the type) to avoid a compiler warning about an unused parameter. So, you can define the constructor this way:

template <class T>
Stack<T>::Stack (size_t)
{
  // your code here
}

NOTE An unbounded stack is never full. Your is_full method should be implemented accordingly.

NOTE Even though an unbounded stack is never full, your push method still needs to return -1 if for some other reason the value could not be pushed on the stack (hint: memory allocation).

NOTE You must define the read method so that it replaces the contents of the stack with the values read in.

NOTE You must define the print and read methods so that they are duals of one another. That is, if a stack's print method is called with a given iostream, and then the read method of any other stack (no matter what it contains) is called immediately after with the same iostream, then at that point the two stacks must be equivalent. How you do this is up to you, but one suggested approach is to print/read the number of elements first, then the value of each element (hint: the order in which you print and read the values can make the read method in particular either easier or harder to implement).

Obtaining the Lab 4 distribution:

At a Unix shell prompt, type ~cs342/bin/lab4. That will copy several files to a new lab4 subdirectory. You can cd lab4 and enter make to compile the code, if you like. However, it will not link until your implementation is filled in.

NOTE: you can use the distribution mechanism to revert one or more of your files at any time. First, delete the file (or better, mv it to a file with a different name, such as Stack.cc.BAD). Then, run cvs update to update your workspace. That will replace any missing files. It will also let you know of any files that you modified but did not delete. cvs is in pkg gnu, in case you don't find it at first.

After obtaining the Lab 4 distribution, copy your Stack.cc files from your Lab 3 to your lab4 directory and modify as necessary. And copy your main.cc from Lab 3, and try to use it with as little modification as possible. You will need to implement the Node methods in Node.cc.

What to Submit:

By the due date, submit all source files from your final solution. Include a laboratory writeup file (named readme) documenting what you did to satisfy this assignment. readme contains a suggested list of sections that you might provide. Please replace the comments in [] with your descriptions. Specifically mention what the most troublesome parts were. These files will be submitted automatically when you execute the command:
make turnin
NOTE: there is a Makefile target that allows you to test what you are going to turn in:
make test_turnin

It places the output that will be turned in into the TEST_TURNIN directory. Please use make test_turnin, and verify that the files that you will submit are correct.


Please see the Lab 2 assignment for hints on compiling templates.


CS 342 home page