Read the FAQ for updates/corrections. Items that have changed from the previous version will be marked in red to make it easier to spot changes.

Checklist

Click here before submitting.

Project 2 Checklist

Project #2 Game Clarifications

Some students have come up with questions on how the game is played. These are clarifications.

Clarifications

Project #2 Updates

You are expected to read updates on a daily basis.

Updates

Project #2 FAQ

Some of your questions may be answered here. Read it to see before sending email.

You are expected to read FAQ on a daily basis.

Project #2 FAQ

Your Responsibility

Read this webpage often. Read the FAQ often. Read README.updates in the posting account often.

Get started right away.

The main part that's missing from the project as of today is the files in the posting account, and the rest of the BNF. However, you should be able to start Task 2, with information provided.

Purpose

1. To templatize a class. In particular, convert ItemSortedList and ItemArrayList into template classes, SortedList and ArrayList.
2. To write recursive functions. In particular, convert all loops in ItemSortedList to recursion.
3. To extend the features of the ItemArrayList by adding an erase() and being able to call a sort on the list.
4. To extend the features of the game.
5. To gain experience with a "function object".
6. To write documentation for the proposed classes for Project 4.
7. To debug code from previous project, so that it doesn't give you problems on this one.
8. To write unit testing classes with a templatized array list.

Academic Integrity Statement

Please note that *all* programming projects in this course (including this one) are to be done independently or with the assistance of the instructional staff of this course only.

Please review the policies outlined on the class syllabus concerning the use of class computer accounts and concerning the University's Code of Academic Integrity. The instructors of this course will review the programs submitted by students for potential violations of the Code of Academic Integrity and if it is believed that a violation has occurred it will be referred to the Office of Judicial Programs and the Student Honor Council.

Hardcoding is considered a violation of academic integrity

Checklist

Click here before submitting.

Project 2 Checklist

Overview

• Task 1 Finish old stuff.

  Debug any code from Project 1, finish the Tokenizer class, and finish the unit testing from Project 1.

• Task 2 Extend Item, ItemArrayList, ItemSortedList

  Modify Item to handle multi-word item names. Write additional methods for ItemArrayList. In particular, add methods to the iterators to do "pointer arithmetic". Also, write an erase() method.

  Remove loops from ItemSortedList and implement using recursion.

• Task 3 Specifications

  Background Reading

  • Writing Template Classes
  • Compiling Template Classes
  • Understanding Comparators (NOW READY)

  You need to templatize ItemArrayList to ArrayList and ItemSortedList to SortedList.

  Then, replace all occurrences of ItemArrayList with ArrayList<Item> and ItemSortedList with
  (10/9) SortedList<Item, ItemComparator> in the classes you wrote for the Sokoban game. (10/9) ItemComparator is in the posting account. You need to finish implementing the class.

• Task 4 sort

  You will write a method to sort an ArrayList (corrected 10/9). This will mimic the way it's done in the STL. However, it turns out to be easier to write the code using pointers and C arrays first, and then convert that code to iterators.

  You may pick whichever sorting algorithm you want. There is a sorting tutorial on the Tutorial webpage. However, you may wish to refer to your textbook for its explanation. Make sure that the code works (test a few examples) if you use the code from the webpage.

• Task 5 Unit Testing, part 2

  Write MovieALQueue.h and MovieALQueue.cpp. Modify MovieQueueUnit.h and MovieQueueUnit.cpp to MovieALQueueUnit.h and MovieALQueueUnit.cpp so it handles an ArrayList of Movies.

  You will re-implement the MovieQueue using a ArrayList<Movie>. You may NOT add a pushFront, popFront method, however. Use only the methods that exist in the templatized ArrayList already.

  The goal of this is to show you that if the implementation changes, but the methods don't change, then you can test it the same way. Except for the minor changes in class name, the tests you ran in P1 should still work.

  operator== and operator!= have been added to the queue, so you may want to add tests for that.

• Task 6 Main project (in BETA).

  Add new features to the game as described below. The BNF has been posted. Now, just a matter of making sure there are no real problems with it.

• Task 7 Documenting classes for Project 4

  This task is due a few days after Project 2. A preliminary description of Project 4 will be posted within a week. You should come up documentation for at least two classes (perhaps more).

Files Provided

Project Description (BETA)

You will now add additional features to the game. Here are the list of new features:

1. The board has arbitrary number of rows and columns. However, to keep things interesting, assume at least a 3 row, 3 column board.
2. The player now has strength. This is an int value, and determines how much a player can push and/or carry.
3. A player can potentially push more than one box at a time, assuming all boxes are adjacent in the direction being pushed.
4. A box now has color. This is a single word. Each box has a unique color (case-INSENSITIVE).
5. A box now has weight.
6. If the player's strength is greater than or equal to the sum of the boxes being pushed, then the boxes can be moved.
7. A player can place food items on TOP of a box. A box can have more than one food item on the box.
8. In order for the player to drop the food item on the box, the player must be carrying the item, and the box must be within one square of the player (in any of the eight directions: north, south, west, east, northwest, northeast, southwest, southeast). The player will specify the box by color.
9. In the "real" Sokoban game, there are target squares, which are certain designated squares.. The goal of the game is to move boxes to the target squares.
10. There will be target squares on the board. You can assume the target squares are not the same squares as walls. However, target squares can initially have up to one food item, or a box on the square.
11. Initially, no food items sit on top of a box. They are only on a box when placed there by the player.
12. The game now stops under three circumstances. First, the player enters a QUIT command. Second, while processing the commands, you reach </command>;, or third, all target squares contain boxes.
13. The number of target squares will be identical to the number of boxes.
14. Initially, all boxes will NOT lie on target squares, i.e., at least one box is not on a target square.
15. The player can query for where items are located, as well as what food items sit on top of a box.
16. If a food item sits on top of a box, it can not be crushed.
17. A player can pick the item off the top of a box by issuing a command, but must still pass over a square to pick it off the ground.
18. Food items do not have any weight (at least, it's neglible compare to the box weight).
19. Food items can now have multiword names (such as "chocolate chip cookie").
20. Food item names are no longer unique. If the name appears twice in the input, the points and names should be updated. (The name will only change in case only, you can only update food items of the same name).

List of Commands

• MOVE

  The player still moves as usual, but the messages can now be different since more than one box can be moved at a time (or possibly none at all).

  Here are the cases:

  • Case 1. Player successfully moves entire distance.

    You should print out the information in the following order.

    • Player successfully moves.
    • Print location of boxes that moved, in the order of the closest box to the box that's furthest from the player. (one line per box that moved). Leave blank if no boxes were moved.
    • Print the items picked up (one line per item picked up), if any, in the order picked up. Leave blank if no items were picked up.
    • Print the items crushed, (one line per item curshed), if any, in the order crushed. Leave blank if no items were crushed.
    Here's the BNF.

       <out1> := "Player successfully moves " <units> " units "
                 [ "EAST" | "WEST" | "NORTH" | "SOUTH" ] <endl>
                 [ "Box is moved from " <coord> " to "
                    <coord> <endl> ]*
                 [ "Player picks up [" <name-of-item> "] at "
                    <coord> <endl> ]*
                 [ "Box crushed [" <name-of-item> "] at "
                    <coord> <endl> ]*
                 "Player is currently at " <coord> <endl>
       <name-of-item> := [ <word> | % ]*
    

  • Case 2. Player UNsuccessfully moves entire distance.

    As before, there are several reasons this will happen. However, this has been modified from Project 1.

    • Player is (eventually) blocked by a wall.
    • Player is not strong enough to move a series of boxes.
    • Player is strong enough to move a series of boxes, but the boxes are blocked by the wall.

    The output is printed in the following order.

    • Prints how far player has moved.
    • Print why player has unsuccessfully moved (one of the three reasons above).
    • Prints the location of the boxes that moved (starting and ending coordinate), in the order from nearest box to player to box furthest away.
    • Prints any items picked up. (One output line per item, in the order the item was picked up).
    • Prints any items crushed. (One output line per item, in the order the item was crushed).
    • Prints coordinate of the player.

     <out1a> := "Player ONLY moves " <units> " of " <units> " units "
                      [ "EAST" | "WEST" | "NORTH" | "SOUTH" ] <endl>
                 [ <errorA> | <errorB> | <errorC> ]
                 [ "Box is moved from " <coord> " to " <coord> <endl> ]*
                 [ "Player picks up [" <name-of-item> "] at " <coord> <endl> ]*
                 [ "Box crushed [" <name-of-item> "] at " <coord> <endl> ]*
                 "Player is currently at " <coord> <endl>
    
     <errorA> :=  "Player is blocked by " 
                       [ "outer wall" | "wall at " <coord> ] <endl> 
     <errorB> :=  "Boxes between " <coord> " and " <coord> " weigh too much (" 
                       <udigits> ") for player's strength (" <udigits> ")" <endl> 
     <errorC> :=  "Boxes between " <coord> " and " <coord>  " is blocked by "
                       [ "outer wall" | "wall at " <coord> ] <endl> ]
    

    Only one of three error messages is printed.
    • In errorA, the player eventually is blocked by a wall. This is the same as in P1.
    • In errorB, the sum of the weights of a series of boxes exceeds the players strength. For example, suppose the player is at (5,0), and there are three boxes at (2,0), (3,0), (4,0), each weighing 100 units. The player has 250 for strength. Since 300 (the sum of all 3 boxes) is too heavy, the player can't move the boxes.

      If the boxes were at (1,0), (3,0), (4,0), and the player moved north 3 units from (5,0), the problem would still exist. The boxes at (3,0), (4,0) could be moved to (2,0), (3,0), but at this point, there are 3 boxes in a row, that exceed the player's strength.

    • In errorC, the sum of the weights of a series of boxes is less than or equal to the player's strength. However, a wall blocks the boxes. For example, boxes appear at (3,0), (4,0), and the player is at (5,0). A wall is at (1,0). The player wants to move north 3 units. The player can move 1 unit north, but that's it. Even though the player has strength to move both boxes, the player can't push the boxes through the wall.
    • The only other unusual case is when the player's strength is less than the sum of the weights of the boxes, and there's also a wall block it. Which error should be printed? In this case, print errorB, since that takes effect first.

• SHOW_FOOD

  The only modification to SHOW_FOOD is the food items name are now listed as words separated by a single space. In P1, you might write [cookie]. Now, it could be [chocolate CHIP cookie].

  Other than that, the format is the same as in P1.

• DISPLAY, DISPLAY_BACKWARD,
  • Empty target squares are indicated by "+".
  • However, if the target square contains a box, then the box is printed as "*".
  • If the target square contains a box with items on top, then print "!".
  • If a target square has a food item, but no boxes, print the item letter in upper-case.
  • The person is now printed with "=", instead of "P".
  • If a box contains food items, but does not reside on a target square, print "$".
  • (10/17) Boxes with no items on it and are not on a target square still use "@".

  Modify the display in the following way:

     <display> := <numbers> [ <line> ]+ <endl> <more>
     <numbers> := <digit> [ <blank><digit> ]+ <endl>
     <line> := <digit> " " <char> [ <blank> <char> ]+
                        <endl>
     <char> := "." | "=" | "#" | <lower> | <upper> | "+" | "!" | "$" | "*"
  

  The display now has line and row numbers. Here's an example with 12 columns and 2 rows.

     0 1 2 3 4 5 6 7 8 9 0 1
  0  . . . = . - # # # # # #
  1  . . . . + ! $ . . . . .
  

  Print the rightmost digit of the column or row, starting at 0. Thus, when you print 10 and 11, print out 0 and 1.

  Print the legend after this as before. However, the legend should include only the items that are on the ground, and not those that sit on boxes. Print uppercase letters if the item sits on a target square in the legend.

• DROP

  This takes two arguments. The item being dropped (which will be in double quotes), and the name of the box to drop it on. There are two error messages. Either the player is not currently carrying the food item, or the box is not near the player. You may assume the player refers to a valid box name.

  The BNF for the input is:

     <drop-cmmd> := % "DROP" %% <dquote> <name-of-item> <dquote> 
                       %% <box-color> % <endl>
     <name-of-item> := <word> [ %% <word> ]*
     <box-color>  := <word>
  

  Hint: use erase() to remove the item from the player's list.

  These are the following output messages. Print exactly one of them.

     <drop-out>  := <drop-good> | <drop-noitem> | <drop-nobox> 
     <drop-good> := "  Player successfully dropped [" <item-name>
                        "] on [" <box-color> "] " <dir8> 
                        " of player at " <coord> <endl>
     <dir8>      := "NORTH" | "SOUTH" | "EAST" | "WEST" |
                         "NE" | "NW" | "SE" | "SW"
     <drop-noitem> := "  DROP ERROR. Player not carrying  [" <item-name>
                            "]" <endl>
     <drop-nobox>  := "  DROP ERROR. Player not adjacent to box [" 
                            <box-color> "]" <endl>
  

  Note: the food item name may contain more than one word, however, the box name is only a single word.

  You should print exactly one message above. If the player is not carrying the item and not adjacent to the box, print that the player is not carrying the item.

  <coord> refers to the coordinate of the box that the item was dropped on.

• PICKUP

  This takes one argument: the name of the item being picked up. This item must be sitting on a box, and be within one square of the current location of the player, otherwise it fails. If successful, the item is no longer on the box.

  The BNF for the input is:

     <pickup-cmmd> := % "PICKUP" %% <dquote> <item-name> <dquote> % <endl>
  

  These are the following output messages. Print exactly one of them.

     <pickup-out>     := <pickup-good> | <pickup-noitem> 
     <pickup-good>    := "  Player successfully picked up [" <item-name>
                           "] on [" <box-color> "] " <dir8> 
                           " of player at " <coord> <endl>
     <pickup-noitem>  := "  PICKUP ERROR. Player not adjacent to item [" 
                                     <item-name> "]" <endl>
  

  <coord> refers to the coordinate of the box that the item was picked up from.

  Note: player can not pick items up off the floor with this command. Players pick up items implicitly by walking on a square that contains an item (but has no box).

  (10/13) pickup-nobox BNF has been removed. The message for pickup-noitem is printed when a player is not adjacent to a BOX with the food item on top. So, even if a player is adjacent to a food item, but the food item is NOT on a box, you still print the pickup-noitem. A better error message would be nice, but this allows the BNF to stay as is.

• BOX_INFO

  This takes one argument: the color of the box. This prints out the coordinate of the box, any items on the box, and if the box is lying on a target square.

  The input BNF:

     <boxinfo-cmmd> := % "BOX_INFO" %% <box-color> % <endl>
  

  You may assume the color is valid.

  The output BNF is:

     <boxinfo-out> := "  The [" <box-color> "] box is at " <coord> <endl>
                        <show-food>
                        "  The [" <box-color> "] box " [ "IS" | "IS NOT" ]
                        " on a target square" <endl>
                        "  The [" <box-color> "] box weighs "
                        <udigits> " units" <endl>
  

  (SEE REVISED BNF below)

  The food items on the box should be listed in the order that it was placed on the box. Notice the syntax is the same as for SHOW_FOOD, except it displays the food items on the box.

  (10/13) When there is no food items on the box, print

    <no-food-box> := "  [" <box-color> "] box has no food items on it" <endl>
  

  since the error message used in <show-food> makes no sense for boxes without food items (makes sense for players).

  Revised BNF (10/17)

  <boxinfo-out> := "  The [" <box-color> "] box is at " <coord> <endl>
                    <boxinfo-show-food>
                      "  The [" <box-color> "] box " [ "IS" | "IS NOT" ]
                         " on a target square" <endl>
                      "  The [" <box-color> "] box weighs "
                          <udigits> " units" <endl>
  
  <boxinfo-show-food> := Food items" <endl>
                           "----*----*"  <endl>
                           [ <food-list> | <no-food-box> ]
                           <endl> 
                           <boxtotal-points>
        <no-food-box> := "  [" <box-color> "] box has no food items on it" <endl>
         <food-items> := [ <food> ]+
         <food>       := "(" <udigits> ") [" <name-of-item> "]" <udigits> " pts" <endl>
    <boxtotal-points> := "The box holds (" <udigits> ") total pts" <endl>
  

• BOX_INFO_SORTED

  The input BNF:

     <boxinfosort-cmmd> := % "BOX_INFO_SORTED" %% <box-color> % <endl>
  

  The output is similar, except <show-food> prints the items in sorted order. You should use sort214 to sort the items. However, you should realize a person can still call BOX_INFO afterwards and access the items in the order placed on the box.

  (10/13) See message above for what happens when box has no food items on it

  (10/17) Look at the revised BNF above.

• TARGET_INFO

  This indicates how many boxes lie on target squares, and which target squares are empty. This method takes no arguments.

  The input BNF:

     <targetinfo-cmmd> := % "TARGET_INFO" % <endl>
  

  The output BNF is:

     <targetinfo-out> := "BOXES ON TARGET" <endl>
                           "----*----*----*" <endl>
                           [ <target-list> | <empty-target-list> ]
                           <endl>
                           "EMPTY TARGET SQUARES" <endl>
                           "----*----*----*----*" <endl>
                           [ "  " <coord> <endl> ]+
     <empty-target-list> := "  No boxes lie on target squares" <endl>
     <target-list> :=   [ "  " <box-color> " " <coord> <endl> ]+
  

  (10/13) Print the boxes in row major order. That is, the boxes should be printed by writing a nested loop where the outer variable is the row, and the inner loop is the column, and printing the coordinates of target squares, in the order visited by the loop. For example, if the target squares are at (0,0), (1,1), (1,3), (2,4), you would print it out in that order, since these are the target squares that would be visited in row-major order.

• ITEM_INFO

  This indicates where an item is on the board. It may be on a square, on a box, on the player, or crushed. You may assume a valid item name.

  The input BNF:

     <iteminfo-cmmd> := % "ITEM_INFO" %% <food-name> % <endl>
     <food-name>     := <dquote> % <word> [ %% <word> ]* % <dquote>
  

  You may assume a valid item name. Notice the food item name is in double quotes since it can contain more than one word.

     <iteminfo-out> := <item-player> | <item-square> | <item-target> | <item-box> | <item-crushed> 
     <item-player>  := "  Player is carrying [" <item-name> "]" <endl>
     <item-square>  := "  [" <item-name> "] is at "
                              <coord> <endl>
     <item-target>  := "  [" <item-name> "] is on target square at "
                              <coord> <endl>
     <item-box>     := "  [" <item-name> "] is on a box at "
                              <coord> [ " which is on a target square" ]?
                              <endl>
     <item-crushed> := "  [" <item-name> "] has been crushed" <endl>
  

  The messages are:
  • Player is carrying the item.
  • Item is on a square, but not on a box, nor on a target square.
  • The item is on a target square, but not on a box.
  • Item is on a box, which may be on a target square.
  • Item has been crushed.

• Invalid command

  If a command does not fall in any category above (or from P1), then it is an invalid command. An invalid command has the following input BNF.

     <invalid-cmmd> := % <invalid-word> [ %% <word> ]* % <endl>
     <invalid-word>  := <word>
  

  That is, it is the name of the invalid command (a single word), possibly followed by other words on the same line.

  Print the following message:

     <invalid-out> := "  [" <invalid-word> "] is an INVALID command" <endl>
  

  The remaining words on the lines should be ignored, and processing begins on the next valid line of command input.

Input file format

(UPDATED)

The format of the input file looks like:

<all> := <dim> <boxes> <target-squares> <walls> <food-list> <player> <cmmds> 

<dim> := % "<size>" % <endl>
            % <udigits> %% <udigits> %
            % "</size>" % <endl>

<boxes> :=  % "<box>" % <endl>
              [ % <one-box> [ %% <one-box> ]* % <endl> ]*
              % "</box>" % <endl>
<one-box> := <coord> %% <box-color> %% <weight>
 <weight> := <udigits>

<target-squares> :=  % "<target>" % <endl>
                       [ % <coord> [ %% <coord> ]* % <endl> ]*
                       % "</target>" % <endl>

<walls> :=  % "<wall>" % <endl>
              [ % <coord> [ %% <coord> ]* % <endl> ]*
              % "</wall>" % <endl>

<food-list> :=  % "<food>" % <endl>
                 [ % <one-food-item> ]*
                 % "</food>" % <endl>
<one-food-item> := % <food-name> %% <points> %% <coord> % <endl>
<food-name> := <dquote> % <word> [ %% <word> ]* % <dquote>
<points>    := <udigits>

<player> :=  % "<player>" % <endl>
             % <coord> %% <strength> % <endl>
             % "</player>" % <endl>
<strength> := <udigits>

<cmmds> :=  % "<command>" % <endl>
                [ % "MOVE" %% <dir> %% <udigits> % <endl> |
                  % "DISPLAY" % <endl> |
                  % "DISPLAY_BACKWARD" % <endl> |
                  % "SHOW_FOOD" % <endl> |
                  % "DROP" %% <food-name>
                     %% <box-color> % <endl> |
                  % "PICKUP" %% <food-name> % <endl> |
                  % "BOX_INFO" %% <box-color> % <endl> |
                  % "BOX_INFO_SORTED" %% <box-color> % <endl> |
                  % "TARGET_INFO" % <endl> |
                  % "ITEM_INFO" %% <food-name> % <endl> |
                  % "QUIT" % <endl> |
                  <invalid-cmmd> ]*
            % "</command>" % <endl>

The BNF doesn't clearly show the following, but they do apply.

• The dimensions (in <size>) are given as rows, followed by columns. You can assume both values are at least 3.
• The order of target squares, walls, food-list, and location of the player, is no longer fixed. They can appear in any order (although they appear once), but they do appear AFTER the dimensions of the board, and BEFORE the commands. Thus, you must look for the opening tag, and use some kind of if-statement to distinguish between the tags.
• There may be blank lines in the input, which should be ignored. Blank lines are defined as 0 or more spaces ending in a newline.
• The commands and name of the food items can be a mix of upper and lower case (plus, possibly digits). You should handle this by being case-INSENSITIVE.
• Boxes have color and weight. The weight is a positive integer.
• Food item names are in double quotes, and may consist of one or more words, separated by one or more spaces..
• There are as many boxes as target squares, which could be zero.
• The player has strength, which is positive.

Assumptions

• You may assume boxes, the player, food items, and walls are on valid locations on the board.
• You may assume the player will move in non-negative units.
• You may assume the commands are valid, i.e., they have the correct name, number of arguments, and type.
• You can NO LONGER assume a QUIT command exists. Obviously, </command> does exist

Requirements/Restrictions

• You must write a SECOND class, beyond the one you wrote in P1. Same restrictions: data members must be private, use public methods. (REQ2-1).
• You must convert to ArrayList from vectors where possible (although a good-faith effort is sufficient). At least one other place (besides the list of items carried by the player) is ArrayList (REQ2-2).
• You should no longer use ItemArrayList and ItemSortedList in your project. They should now be ArrayList and SortedList with the appropriate instantiations. You can comment this in the header files (REQ2-3).
• Currently, you should still not use implement classes using inheritance (though the penalty, if any, will be minor).
• You should convert all loops to recursion in SortedList>

For each of the REQ, put a comment in the code and/or header file where you have met these requirements. For example, you would write // REQ2-3. This way, the graders can easily find where you have met the requirements. If these are missing, we may deduct points, even if you have met the requirements.

Writing Classes

This project may require that you write your own classes. You should pick sensible classes, and you can write as many or as few as you want.

Here are some requirements/restrictions:

• Each file must use the following naming convention. <name>.mine.cpp where <name> is the name of the class. Thus, if you create a class called Foo, you should name the file Foo.mine.cpp and Foo.mine.h.

• Each file must have documentation, e.g. Foo.mine.dcmt. You can leave out preconditions, postconditions, efficiency, etc. The description can be fairly brief per method. Ideally, someone reading your documentation can tell what the code does.

  At the top of the file, after your name, etc. Explain why you felt you needed this class.

• If you wish to submit a Unit test class, you can do so. Label it something like: FooUnit.mine.cpp and FooUnit.mine.h. You won't be graded on it, however. (It might earn a little extra credit, but no guarantees).

• No public data members. They must be private.

• No global variables.

• Try using const whenever possible.

• Write copy constructors/destructor/assignment operator only if you have to (i.e. implicit versions are inadequate).

• The classes should be SENSIBLE. The purpose of writing a class is NOT to just get the whole project to work, but to write a reasonable class that someone, in principle, could reuse. Even if they couldn't, an experienced person would say "That's a well-designed class" rather than "you just wrote the bare minimum, because you were trying to get the project done".

• Keep in mind that the project continues on, and while it may not be obvious you need a class now, you may need classes later on. So, decide if you would rather spend that time now.

• Do not use inheritance to implement classes.

• Do not alter methods in ArrayList, SortedList to complete the project. In reality, if you had someone else's classes, you would have to deal with whatever problems it had.

You may feel free to use whatever string methods or vector methods you can find in the book, etc., unless it is not in the spirit of the project (e.g., don't use vectors, when you are asked to use a SortedList).

Submit Reponsibilities

If your project successfully submits, there is still a small probability that your project IS NOT CORRECT, and therefore may lose points.

Therefore, you should NOT ASSUME that submitting successfully means you have passed primary input.

To best ensure that you HAVE passed primary, you should test your TAR file before submission. This means the following:

1. Copy your tar file to a temporary subdirectory (which should be empty other than this file).
2. Untar the file
3. Copy the primary input and output to that directory.
4. Type "make" with the appropriate project number.
5. Input redirect the primary input to your executable and output redirect it to a file (e.g., my.out).
6. Run diff -bwi between your output and the primary output.
7. If the differences are only blank lines, you should be ready to submit.

Failing to follow these procedures may result in a project that "submits" (due to some glitch), but may not actually pass primary input.

Extra Credit

The project is worth 105 points. So, there's already 5 extra credit points. If you write a unit testing class for an additional class in this project, you may receive a few extra credit points (5 points or less).

How to Submit Your Project

In order to successfully submit your project, it must pass the primary input and produce the primary output. The primary input will be sent to your project using input redirection.

   p2 < primary.input

Your program MUST produce the executable p2, EXACTLY, when the command "make" is run with "p2" as argument. Thus, you must use a makefile named exactly "Makefile".

Your makefile must generate .o files , and you must not #include .cpp files (unless used for templates). You must link .o files to create your executable. You must also use macros in your makefile. Suffix rules are permitted.

We will use "diff -bwi" to test your code. This ignores case, treats N blanks as 1 blank, treats N blank lines as 1 blank line. We will also strip all blank lines from your input when matching to ours. However, diff is sensitive to punctuation, number of dashes, etc. so you should attempt to make your output match ours as closely as possible otherwise you may not be able to submit your program. If this is the case (that your program does not submit) you must fix your code until the output it produces matches that of the primary output. Note: "hardcoding" output is a violation of the University's Code of Academic Integrity.

To submit your project you must first combine the following files (and only these files) into a single tar file using the Unix tar command:

You may name your tarfile anything you want, but p2.tar is the suggested name.

NOTE! You should make a backup copy of all your files BEFORE attempting to create your tarfile!!!! You have been warned.

After creating the tar file you should submit that one file using the following command:

submit p2.tar 2

where p2.tar can be replaced by whichever tar file you have created, and 2 refers to the current project,

See the class syllabus for policies concerning email Last Modified: Tue Feb 12 19:48:57 EST 2002