Project 2

The project documents will be added to this page as they become available. If you get a page that says "not yet available," it should become available in the future. Ask about it only if we announced that it was supposed to be available.

Files listed as text are plain ASCII text files. The should display in your browser with correct formatting, but can also be downloaded from the course file server; downloading with an ftp utility set to ASCII text mode is recommended for code and sample files to avoid line-ending problems.


Component Specification Files

The files below are "starters" that provide code and strings that you should use in your code. The files with "skeleton" at the beginning of the name provides a code "skeleton" that your project must use, but is incomplete in a variety of ways. For example, the skeleton for a class specifies the public interface functions and possibly some key member variables, but is missing lots of the actual implementation. You have to study the specifications in the document, and the comments in the supplied file, and figure out what code to add to make the complete version of the file. Give the complete version of the file a name without the "skeleton_" prefix. So you will start with "skeleton_String.h" and end with a complete and correct "String.h".


Simple programs like the above are what you should use as a "test harness" to test your components separately and systematically. However, these are demos - not complete tests.

Behavior Samples

The following sample behavior files illustrate the program behavior and contain all of the different output message text strings produced by the program (see the strings.txt file). Your program should match these samples exactly so that you can be sure it is producing all of the different kinds of messages correctly. However, these samples are not a complete test of your program. Your program will be tested for a large number of other possible inputs and input sequences. The console interaction files are a capture of the console display during the program run. The _in.txt and _out.txt files are for you to use with redirected I/O. When given the _in.txt file, your program's stdout output should match the _out.txt file exactly. The other output files are written during the by the program, and your program should produce files that match exactly with these samples.

The following sample illustrates the "normal" behavior of the program and contains the corresponding messages. Your program should reproduce the output files exactly.

The following sample shows the error messages produced by the program and the "rollback" from a failed restore. Your program should reproduce the output file exactly.

The following sample illustrates the behavior of the program when you input excess whitespace and use "type-ahead." Your program should reproduce the stdout and the output files exactly.

These samples demonstrate the program behavior and are supposed to contain every possible type of output message string so that you can prevent your autograder score from being affected by spelling errors and typos.

These samples are not a complete test of your program!!! Your program will be tested for a large number of other possible inputs and input sequences. You must devise your own complete test set to find the bugs in your code.

The console outputs are a saved copy of a console window after entering the commands by hand. The stdin input file is suitable for redirecting input, and the stdout output can be compared with the redirected output of your program. Your program should match the stdout output.

Other Information

See the course web page for how to compare files and redirect I/O. In the examples directory on the file server you can find the redirect_io module that you can use to redirect I/O from a C program on any platform. You can use this to help test your program's output against the supplied samples. The instructions are in the header file.

Autograder tips

The autograder for this project has a series of input/output correctness tests and component tests similar to that of Project 1. Some of the String and Ordered_list standalone tests are similar to the supplied demos, but are more elaborate.

It is a good idea to test your components as you develop them (see the project document). You can get an autograder evaluation of the components before you have finished the entire project.

The component tests all use the same build makefile, so the autograder tries to compile a Person.cpp with the your Person.h even if the testing is only of String and no use is made of Person functions. Thus, if the Person.h or .cpp fail to compile, then the build will fail. To get String and Ordered_list tests independent of the other components, do the following:

Submit ALL of the required project files. But you can submit empty Person, Meeting, and Room .h header files. Because a compiler often complains if given an empty translation unit, submit dummy .cpp files for these components containing a dummy function like void Person_dummy() {}. Do similarly with String or Ordered_list depending on which component you are testing. A dummy p2_main.cpp file should have an int main() {return 0;} dummy function. Your Utility.h, .cpp file should have at least the specified contents.

Alternatively, you can fix the header files to compile correctly along with dummy .cpps, but an empty header is the easiest way to get one that works!

Many of the component tests will fail to compile unless your p2_globals module is correct and your Utility has at least the specified contents, so create them first. Also review the project document about what Utility is allowed to depend on; violating those specifications will result in failed builds on some of the component tests.