Several other test inputs/outputs have now been provided and are in the posting account in the following directory:

No. Any program you write should not have memory leaks - meaning that if your program dynamically allocates any memory, it must also safely/correctly deallocate that dynamic memory. This was implicitly assumed in the project description however a few people thought that it would be ok if their program had a memory leak (or "didn't clean up after itself") and thus it was deemed necessary to explicitly state here that this was not permitted.

There are several ways to print files:

• If you have your own printer - just go to the class webpage and all the files are available there.
• If you do not have your own printer - you can use the "OIT printers" from your class account - Note that these are FREE for printing CMSC 214 related material (and nothing else). To print a text file you type:

  qpr -q prl  <filename>
  

  or:

  qpr -q csc-ps -x  <filename>
  

  where <filename> is the name of the file you want to print for example qpr -q prl csll.h would print out the file csll.h to the line printer (which is wide paper with each page connected). If you print to the csc-ps "queue" (printer) then it will be on "regular" paper.

  The one downside to the free printing is that in order to pick up the printout(s) you must go to room 1299 of the AVW Williams Building (which is open 24 hours a day and is in the outside corner of AVW closest to the Engineering/Math Buildings).

• Printing to a WAM lab printer - you have to pay for this (10 cents a page) and you just need to know the NAME of the printer that is in the lab you want to print to - if it is wam1-ps then you would type qpr -q wam1-ps csll.h and that should work - if not ask someone for help or contact the OIT helpdesk (www.helpdesk.umd.edu)

Yes, the two header files were very minimally changed - in particular the final line (#endif) was changed from (#endif CSLL_H) to (#endif) - this was due to compiler warnings that were generated by the header files with this extra "token" on the #endif lines. This was corrected by approx. 2pm on the day the files were posted.

No. You do not have to write them all or use them. You must however leave the prototypes in the header file. None of them will be individually tested. Hopefully it is obvious that not all of them are needed (for example printForward or printBackward are not needed - and the same may be true for other ones). Note however that some of them may be needed (the ctor for example) and you should write those if they are necessary for your code to work properly.

Your program will be compiled as specified on the project description and tested that way only (by inputting a "transcript" and viewing its output). Your source code will be checked to make sure it uses the linked list appropriately.

When you come to see someone in office hours for help on your project, you should always bring a current printout of your code and if possible a printout of the compiler error messages (if there are any) and if it compiles a printout of the programs output (and the input used to generate that output). If you want to get the output of the compilers error messages you will need to redirect error output as follows:

%  cxx  main.cpp  csll.cpp  >&  my.comp.errors

Having the requested information above will assist the instructional staff in being better able to assist you and others who are waiting to be assisted. Please also understand that the office hour room is a shared resource with other classes and we ask that you be respectful of the room and others using the room.

Another VERY IMPORTANT thing to do prior to going to office hours is attempt to "debug" your code as much as possible when you have a problem and that way when you see the TA you can point to the line (or lines) of code causing the problem (it should typically only be one line) and explain to them what the problem is and hopefully they will be able to figure out the problem (and a solution) and explain it to you so that you can determine how to fix it. When "debugging" code you can either attempt to use a debugger (details of which will be posted with later projects) or just use good old fashion debug cout (or cerr) statements:

    cout << "GOT THIS FAR" << endl;  // very important to use endl;
    someFunctionCall();
    cout << "DIDN'T GET THIS FAR" << endl;  // and cout is recommended over cerr

A FAQ is a list of Frequently Asked Questions and in particular the FAQ's for projects in this class will have questions listed in reverse chronological order (meaning the most recent question will appear at the top of the FAQ list and the first question asked/answered will appear at the bottom of the list).