Project 2 is worth 7% of your grade.

NOTE: failure to follow ANY of the general guidelines outlined in this and prior project descriptions in this course may result in the loss of points on this project.

As with all projects it is extremely important to begin early. There are generally a number of details contained in a project description such as this one. Please note that failure to follow the details outlined in the project description could result in a substantial loss of points so it is very important to pay close attention to the project description.

To modify project 1 so that templates are used.

In this project you will modify the doubly-linked list data structure (EventList) you defined in Project #1 and will transform it into a doubly-linked list (DLL) class template. After you have implemented this project, you will be able to define doubly-linked lists that not only store Events, but also any object you want. In Project #1, EventList contained a list of Events. Each event's primary key was a string (the event's title). In this project, the doubly-linked list class template can store objects with any type, whose primary key can be of any type (instead of Event and string, respectively). The following are examples of lists you could create (some of them have nothing to do with this project):

DLL<Event,string> eventlist1;  // list of Events where the primary
                               // key is string (as in Project 1)

DLL<Student,int> studentlist;  // list of Students where the primary key is
                               // an integer (for example their id number)

DLL<Car,VIN> dealerlist;  // list of cars where each one
                          // one is identified via a VIN.

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 and below concerning the use of class computer accounts (Acceptable Use Guidelines) and concerning the University's Code of Academic Integrity. The instructors of this course will review all of 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.

Note that "hardcoding" is also considered a violation of academic integrity.

If you are unclear about any of the policies of this course you should ask either of the instructors for further clarification. NOTE: unless explicitly specified otherwise these policies apply to all assignments in this course:

Code of Academic Integrity
Guidelines for Acceptable Use of Computing Resources

All your programs in this course should be written in ANSI C++, which means they must compile and run correctly with "cxx -w0 -std strict_ansi" on the OIT UNIX Class Cluster (dc.umd.edu).

Your program must have a comment near the top which contains your name, login ID, your section number, your TA's name, an estimated time it took to complete the project (in hours) and an original description of the action and operation of the program (thus at least 6 items neatly organized and easy to read).

Your program should be written using good programming style and formatting, as discussed in class and throughout your textbook. For this project, style is considered to consist of:

• neat and proper indentation and formatting (including both "horizontal" and "vertical" whitespace - blank lines)
• keeping all lines less than 81 characters long
• writing clear and readable code
• commenting code as necessary - each method/function you define in a .cpp (source) file must have a "header" comment at the top of the method/function including the name of the method/function, a brief description of what it does (including any data members it modifies).
• generally (but not necessarily always) any "stretch of code" longer than 6-10 lines should have one or more comments (sometimes certain sections of code will have more comments than others but in general there should be comments interspersed with your code).
• using meaningful and descriptive names for functions and variables

Answers to "frequently asked questions" will be posted via the main projects page. Prior to asking a question or submitting a project you should check the FAQ to see if any important information has been covered there. In addition to answers to FAQ's, any important information pertaining to a project will be posted on it's FAQ.

Note that email regarding project questions will go unanswered and the means for obtaining assistance on a project is through office hours. See the course syllabus for additional information regarding these policies.

Overview of the classes

The Name, NameList, and Event classes you implemented for Project #1 will be used for this project. If you did not complete any parts of Project #1 with respect to those three classes, it is your responsibility to fix them before you start working on this project. If your Name, NameList and Event classes have been implemented correctly from Project #1, you should be able to use them in Project #2 without any modifications (copy the .h and .cpp files from your Project #1 for use in Project #2). Note that in testing Project #1 we may not have tested every aspect of these three classes however they may be "retested" when grading Project #2 for things that were tested in Project #1 and for things that weren't tested (but we will not test the extra credit parts).

There will be a new class called AMember. This class represents a member of an Athletic Association. A member has name, year, email, and other personal information. The EventList class will disappear; you will implement a class template called DLL that will be used (by defining a template class with parameter Event and string) to replace EventList in your application. New methods (which you must implement) that deal with AMember objects have been added to the DataManager class.

Classes to implement or modify:

Below, we provide a description of each of the classes you are to implement. For each of these classes there is a .h file that can be found in the posting account. The name for the methods to be described are as specified in the .h files (when in doubt follow the name presented in the .h file). You can modify copies of the files posted only if the project specification below requires or permits you to do so. There are at least two files you are NOT expected to modify: the DataManager.h and main.cpp files (and possibly others).

There will be some references to BNF entries defined in the description of project #1 (we will not provide the description for those entries in the current project description)

Class Name	Brief description of the class
Name, NameList, and Event	Same as in project #1.
AMember	This class represents a member/person in a specific athletic association. It stores the member's name and other information necessary for the association to store about each member.
DLL	This class template represents an ordered list of items. It is implemented using a doubly-linked list class template where each node of the list stores information about the template items in the list. DLL will be used to replace EventList from project #1.
DLLIter	This class represents an iterator for the DLL class. It will allow us to go through each one of the elements of a DLL. This class will replace the EListIter class from project #1.
DataManager	The execution of commands (e.g., adding/removing Events) will be possible via this class. In the main() function of the application an object of this class will be created, and any processing requests will be sent to the DataManager object for processing. This class (as well as main.cpp) has been modified for project #2 to incorporate the new additions/modifications.

Details of the classes to implement

In this project the C++ string class is being used to represent strings. Make sure you include the <string> and not the <string.h> library header file in order to use the C++ string class library.

a. Private data members
-----------------------
  i. name - Name object representing the name of the association member. 
 ii. year - int representing the year this person became a member.
iii. email - C++ string class object representing the email address of
             the member
 iv. type - C++ string class object representing the type of member (e.g.,
            Athlete, Coach)

b. public methods
-----------------
   i. Constructor - This constructor will have default values of a default
                    Name object, CUR_YEAR, "NONE", "NONE" for the name, year,
                    email, and type respecitvely.  (NOTE: CUR_YEAR is a
                    constant defined in the header file)

  ii. Copy Constructor - You must determine whether it is necessary to
                         implement this method or not.

 iii. Destructor - You must determine whether it is necessary to implement
                   this method or not.

  iv. operator= - You must determine whether it is necessary to implement
                  this method or not.

   v. getName - returns the name.

  vi. getKey - returns the name (yes, the name is the key)

 vii. getYear - returns the year.

viii. getEmail - returns the email.

  ix. getType - returns the type.

   x. operator>> - You must overload the input operator.  You must
                   use the readin method (to be described below) for the
                   overloading.

  xi. operator<< - You must overload the output operator.  You must
                   use the writeout method (to be described below) for the
                   overloading.

c. private methods
------------------
   i. readin - initializes the current object with information read from
               the designated input stream.  Returns the input stream
               used.  This method MUST BE USED to overload the input
               operator (above).  The input is described by the BNF
               entry <amember_in>

  ii. writeout - send information abou the current object to the
                 designated output stream.  Returns the output stream
                 used.  This method MUST BE USED to overload the output
                 operator (above).  The output is described by the BNF
                 entry <amember_out>

d. BNF
------
   <amember_in> ::=
         <maybews><name_in><ws><year_in><ws><email_in><ws><type_in>

      <year_in> ::= (a positive int value)
     <email_in> ::= <projstring>
      <type_in> ::= <projstring>

  <amember_out> ::= <name_out><type_out><year_out><email_out>
     <type_out> ::= " ("<type_in>"), "
     <year_out> ::= "Member Since: "<year_in>", "
    <email_out> ::= "Email: "<email_in>

e. Additional Info
------------------
  i. You cannot add any public methods (except the copy constructor,
     destructor and assignment operators if you think any of them are
     necessary).  NOTE: you should not implement the copy ctor, dtor
     and operator= if they are not necessary, however if they are
     necessary for "safe" use of your class (no memory leaks, etc.) 
     then you must implement them - points may be deducted if you
     implement them when they are not needed or you do not implement
     them and they should be.  This applies to all classes you
     implement in CMSC 214 unless explicitly stated otherwise.

 ii. You cannot add any data members (public or private) to this class.

iii. You can add private "helping" methods if you want (for example a free()
     or copy() method).

 iv. You cannot add friend functions or anything else to this .h (header) file.

  v. You do NOT have to "check" an email to make sure it is valid (for
     example finding if an @ sign is in it).

  NOTE: you can use your EventList implementation of a doubly-linked list
        in order to implement the DLL class template.  An instantiation of
        this class template (with the objects Event and string) will be
        used instead of the EventList and thus you will NOT be turning
        in the EventList.cpp or .h files (just use them as a basis for
        creating the DLL.cpp file).

a. Template parameters (2 total)
----------------------
  i. DLLData - the first parameter representing the type of the data
               to be stored in the doubly-linked list.  This type must
               have a getKey() member function which returns a key of
               type, DLLDataKey.

 ii. DLLDataKey - The second parameter representing the type of the key
                  element associated with the kind of element to be
                  stored in the list.  DLLDataKey must support the
                  following operations: ==, !=, <, >, <= and >=

  Your template declaration must be as follows:

  template <class DLLData, class DLLDataKey>
  class DLL
  {
     // YOU MUST PROVIDE WHATEVER IS NECESSARY AT THIS POINT
  }

  In Project 1, DLLData was Event while DLLDataKey was string
  (the key was the event title, which was a string).

b. Node definition
------------------
   We have provided a template structure declaration for the the node
   to be used in the DLL implementation.  The name of the structure node
   will be: DLLnode
   No changes are required for this node.  (In particular, don't change
   DLLnode into a class, i.e., don't add member functions to DLLnode).

c. Member functions
-------------------
   The same set of methods (functions) available in the EventList class
   will/must be available in the class template DLL.  The only difference
   is that functions, instead of dealing with an Event object, will be
   dealing with a template parameter representing any kind of object.
   In addition, functions, instead of refering to a string type (as the
   primary key type of the objects being stored), will refer to a template
   parameter representing the type of the key element associated with the
   type of object being stored in the list.

   NOTE: you must copy all of the public member functions from the
   EventList class into this class and modify them as required to make
   them work properly with this class template.

   You can not add or remove functions from the public section (just
   modify them so that they become parameterized by a template type
   when needed).  You may add private helping functions as needed.

   TO CLARIFY: you MUST modify any public member functions so that they
   become parameterized by a template type when needed and the function
   names MUST be identical to those found in project #1 for the EventList
   class.

d. Data members
---------------
   You may NOT add any data members to this class other than the two
   private members from project #1 - in particular the member named
   first and the member named last both of which are pointers
   to node structures.  The DLL must be a "standard" doubly-linked list
   WITHOUT any enhancements (no "dummy/header node", no circular list) -
   just a first and last pointer and the list in between.

   Although in project #1 you were permitted to add extra private data
   members to the EventList class you may NOT add private data members
   to this class (or any of the classes in this project).  Additionally
   you may not add public data members.  If you added a private data member
   in project #1 you must fix your code so that it does not depend on/use
   that data member.

e. Additional info
------------------
    i. You must use the specified template parameter names provided.

   ii. Your implementation must be in a file named DLL.cpp

  iii. The BNF for printForward and printBackward will basically stay
       the same.  <event_out> will be replaced with the corresponding
       output BNF entry of the object stored in the list (e.g,
       <event_out>, <amember_out>, etc.).  Also, the headers and
       footers used will change as follows:

       **************** Printing Forward ****************

                          instead of

       **************** Printing Events Forward ****************



       ************** End Printing Forward **************

                          instead of

       ************** End Printing Events Forward **************



       **************** Printing Backward ****************

                          instead of

       **************** Printing Events Backward ****************



       ************** End Printing Backward **************

                          instead of

       ************** End Printing Events Backward **************


   iv. Your class template DLL implementation must allow you to define
       any doubly-linked list of elements that may have any specified
       key.  So, for example, you should be able to define:

         DLL<Event,string> eventlist1, el2;
         DLL<AMember,Name> amemberlist;
         DLL<AMember,int> amemberlist2;
         DLL<Student,int> studentlist;
         DLL<Car,Tag> carlist;

       Notice that these are examples, and we will not be using some
       of these template classes in our project.  Additionally it is
       hopefully evident that they might not all work in the same program.

    v. You can assume that any data component (e.g., Event object)
       class used with the class template DLL will have a method
       getKey() const returning the value of the key and that this
       value will match the type of the DLLDataKey parameter provided.

  NOTE: The declaration for this class is in the file DLL.h.  The
        methods must be implemented in the DLL.cpp file.

a. Class declaration
--------------------
   We have provided a class template declaration for the iterator
   to be used with a DLL implementation.  The name of the iterator
   class will be: DLLIter  No changes are required for this class
   template declaration.  DO NOT MODIFY THE DLLIter class definition
   - meaning you may not add member functions or data members.

b. Implementation
-----------------
   You must provide the appropriate implementation of the methods
   associated with the class template DLLIter and they must be
   written in the DLL.cpp file.

a. Private data members
-----------------------
   i. eventlist - DLL object representing a list of Event objects where
                  the key is the title of the Event (a string).

  ii. amemberlist - DLL object representing a list of AMember objects
                    where the key is the Name of the member (a Name).

b. public methods
-----------------
   You will modify the methods previously implemented in Project #1,
   so that they can now work with the template classes defined.  YOU
   WILL NOT CHANGE THE PUBLIC INTERFACE PROVIDED in the DataManager.h
   file we have provided for Project #2.  You must use this new version
   of the DataManager.h file and not the one provided for Project #1.
   This version defines a doubly-linked list called amemberlist that
   will be used to keep track of the list of association members (and
   a list to keep track of the events).

   The following are the new methods that have been added to the
   DataManager:

    i. addAMember - Adds the member represented by the parameter to the
                    AMember list.  If the add operation is successful
                    (meaning a "new" member has been added to the list)
                    then a message according to <add_amember_succ> will
                    be generated.  Otherwise, a message according to the
                    <add_amember_fail> will be generated (see the BNF
                    found below).  The member will be placed in the list
                    in ascending lexicographical order based on the
                    members name.

   ii. delAMember - Deletes the member with the specified Name from the
                    AMember list.  If the operation is successful,
                    (meaning an existing member has been deleted from the
                    list), a message according to <del_amember_succ>
                    will be generated.  Otherwise a message according to
                    <del_amember_fail> will be generated.

  iii. printAMemberListForward - Prints the list of association members
                                 according to the BNF entry
                                 <print_forward_manager> but assuming
                                 an <amember_out> entry instead of
                                 <event_out>

   iv. printAMemberListBackward - Prints the list of association members
                                  according to the BNF entry
                                  <print_backward_manager> but assuming
                                  an <amember_out> entry instead of
                                  <event_out>

    v. printPartMembersYears - prints the names of participant members of a
                             particular event that are part of the
                             association member list and that have been
                             members of the association greater or equal to
                             the number passed in.
                             The output will be generated according to the
                             BNF entry <namelist_out_two>   Read (d),
                             part v, below.  For example if the number 8
                             is passed in only those members who have been
                             in the association 8 or more years should be
                             displayed.

c. BNF
------     
  <add_amember_succ> ::= "Member "<name_out>" added successfully."
                         <endl><endl><endl>

  <add_amember_fail> ::= "Adding member "<name_out>" failed."
                         <endl><endl><endl>

  <del_amember_succ> ::= "Member "<name_out>" deleted successfully."
                         <endl><endl><endl>

  <del_amember_fail> ::= "Deleting member "<name_out>" failed."
                         <endl><endl><endl>

  <namelist_out_two> ::=
     "Assoc. members in the participants satisfying the year restrictions:"
                     <endl> <namelist_out_nonempty><endl><endl>
    |
     "Assoc. members in the participants satisfying the year restrictions:"
                     <endl><endl><endl>

d. Additional Info 
------------------
  i. Notice that every command after completion generates two newlines.

 ii. All of the above methos have void as the return type.

iii. You must implement printPartMembersSal printPartMembersYears using an
     iterator (of the appropriate type) over the association member list.

 iv. There may be association members (in the association list) that are
     not part of any participant lists.  Also participants do not need
     to be part of the association list.

  v. If the event is not in the event list (for printPartMembersSal
     printPartMembersYears), you should print:

     "Assoc. members in the participants satisfying the year restrictions:"
                     <endl><endl><endl>

a. Your project will read commands that will be processed by the main()
   function in the main.cpp file.  Note that unless specified otherwise
   all input will come from standard input (cin) and all output
   should go to standard output (cout).  If you are debugging
   your code you can print to cerr or cout just remember to remove or
   comment out all debug statements when you submit otherwise you may
   lose substantial credit.

b. The command used in Project #1 in the input (ADDEVENT, ADDTOPART,
   ..., FINEVENTSOF, ...) will be available in this project and they
   must work as specified in Project #1.  NOTE: you do not need to
   do the extra credit parts of project #1 and they will not be
   retested in project #2.

c. The following commands have been ADDED for this project (the BNF
   for the commands follows): 

       i. ADDAME - adds an association member to the association
                   member list.
      ii. DELAME - deletes an association member.
     iii. PRIAMESFORW - prints all the members in the association
                        list (forward)
      iv. PRIAMESBACK - prints all the members in the association
                        list (backward)
       v. PRINAMESYEAR - prints the names of participants of a particular
                         event that are part of the association member list
                         and that have been members greater than or equal
                         to the number of years specified.

d. BNF (These BNF entries are extensions to the ones provided in
        Project #1).

      <actual_command> ::= <add_amember_com> | <del_amember_com> |
                           <print_amemberl_com> | <print_names_year>
                           | ... | <quit_com>
     <add_amember_com> ::= "ADDAME"<ws><amember_in>

     <del_amember_com> ::= "DELAME"<ws><name_in>

  <print_amemberl_com> ::= "PRIAMESFORW" | "PRIAMESBACK"

 <print_names_year> ::= "PRINAMESYEAR"<ws><title><ws><year_in>

e. The format of the outputs for the above commands are as specified in the 
   DataManager class.

f. The files primary.input and primary.output in the posting account show
   examples of some of the commands and the expected outputs.

a. We will use a main function (provided in a file called main.cpp available
   in the posting account) that will read commands from the user and then
   call the appropriate DataManager method in charge of handling the command.
   YOU CANNOT MODIFY THIS main.cpp FILE IN ANY WAY.  It is considered the
   driver of the whole application and we will use it to compile your
   system during grading.

b. The main.cpp main() function has for each one of the possible operations
   in the DataManager class an entry that allow us to execute that operation
   with a set of values provided in the input.  For example, if we want to
   add an event, then the addEvent method of the DataManager will be called
   after the command name (a C++ string class object in capitals called
   "ADDEVENT") followed by the event information (as defined in <event_in>)
   have been read from the standard input.  Check the main.cpp file in order
   to identify each of the command strings to be used.

1. Many requirements for the implementation of this project have been specified throughout the methods description provided above; double check those requirements are satisfied by your project.
2. You can not refer to the EventList class anymore in your code. Instead, use the template class DLL<Event,string>
3. You can not refer to the EListIter class anymore in your code. Instead, use the template class DLLIter<Event,string>
4. You must use the DLL<AMember,Name> amemberlist data member in order to keep track of association members.
5. Any iterations required over the association list or the event list in the DataManager class must be done using the required template class iterator.
6. The EventList.h and EventList.cpp files must not be part of your code anymore.
7. There must be a file called DLL.cpp that will contain the class template(s) corresponding to the doubly-linked list and the iterators.
8. You must have an instantiation file named Instantiations.cpp   Every template class used by your program must be instantiated in this file. Your program must link in this instantiation file when compiling the executable.
9. The DLL class MUST IMPLEMENT A TEMPLATIZED DOUBLY-LINKED LIST OTHERWISE YOU WILL RECEIVE A GRADE OF 0 FOR THIS PROJECT EVEN IF YOUR PROJECT GENERATES THE PRIMARY OUTPUT.
10. Primary Output Requirements - Your project must generate results that match the primary output when run with the primary input and the main.cpp file provided. The results generated by your program will be considered correct if and only if this command reports no differences. The expected primary input and output are available in the posting account. ANY PROJECT NOT GENERATING THE CORRECT PRIMARY OUTPUT WILL RECEIVE A GRADE OF 0.
11. YOU CANNOT ADD FRIEND CLASSES AND/OR FRIEND FUNCTIONS to any of the classes in this project. We have already specified in the .h files which functions and/or classes are friends.
12. YOU CANNOT MODIFY THE HEADER FILES IN ANY WAY except when explicitly stated otherwise (and only as explicitly stated otherwise). You may write "helping" code inside the source (.cpp) files as you see fit/necessary however you can NOT have any global variables (with the exception that global constants would be allowed).
13. YOU MUST USE THE main.cpp FILE WE HAVE PROVIDED.
14. YOU CANNOT USE INHERITANCE, NOR THE STL (Standard Template Library) IN ORDER TO IMPLEMENT THIS PROJECT.
15. You can NOT use files or any type of fstreams in this project.
16. During the grading of your project, we may test your code with a main.cpp that is different from the one we provided. That means that those functions not necessarily tested by the main.cpp posted may be tested. Make sure that copy constructors, destructor and assignment operators have been implemented in such a way they work correctly no matter what main.cpp we provide.
17. Your code must not produce memory leaks. As long as it does not have leaks nor does it "wastefully" use dynamic memory, you may assume that memory allocations will always be successful.

1. Although this project is not as long as the last one, you must start working on it immediately (plus you have less time to work on it than the last one). DO NOT WAIT UNTIL FEW DAYS BEFORE THE DEADLINE. Office hours are usually crowded the days before the deadline; if you wait until the last minute you might not be able to get the help you need and it will be very difficult to complete all the required tasks in time.
2. Start by fixing (if necessary) the "supporting" classes (Name, NameList, Event) before you move on to the harder parts.
3. For each class you implement, you should (must) have a test driver that verifies the methods have been implemented correctly. Save those test drivers for future reference.
4. Keep backups of your projects (in a special directory separate from the one you do your main working in).
5. Remove any unnecessary files from your account. The compilation process can be interrupted if not enough disk space is available (familiarize yourself with the UNIX quota command).
6. See the FAQ online throughout the project for other possible hints.

For this project (and the rest of them) you must make a UNIX Makefile to manage the compiling of your project. The makefile must be named makefile and should be written so that the first target is p2 and that typing make p2 or just make will result in the necessary files being compiled to create the executable p2 which can then be run as specified below in the Sample I/O section. Note that your makefile should create (and leave) the necessary .o (object) files and should not recompile unnecessarily (meaning it should not have redundant/incorrect dependency lists for the targets). Your makefile does not have to have any "extra" targets such as make clean or make tar however it is ok if it does.

The makefile must use the cxx compiler with the -w0 and the -std strict_ansi options when compiling.

NOTE THAT YOUR PROJECT WILL NOT SUBMIT UNLESS IT HAS A WORKING MAKEFILE and thus you are strongly encouraged to test this well in advance of the due date to make certain your makefile is working properly. If you have difficulty using the makefile reread the makefile tutorial in the posting account:

~fjm14001/Tutorials/Miscellaneous/makefile+tar.g++

When compiling your program should not generate any compiler warning messages.

For this project you will be provided with a primary.input and primary.output file. Both of these files can be found in the posting account in the appropriate directory. YOU SHOULD COPY THE primary.input FILE FROM THE POSTING ACCOUNT - DO NOT ATTEMPT TO TYPE THIS FILE IN OR CUT AND PASTE IT FROM THE WEBPAGE - INSTEAD, COPY IT (using the UNIX cp command) DIRECTLY FROM THE POSTING ACCOUNT.

In order to pass the MRC (minimum running criteria) for this project your program must generate the primary.output when tested with the primary.input as follows:

%  make  p2
%  p2  < primary.input  > my.output
%  diff  -bwi  primary.output  my.output
%

The first line (make p2) is the step to compile the project - note that you should strive to have NO COMPILER WARNINGS (points may be deducted for having compiler warnings). Note once again: you must use the cxx compiler in your makefile and that the -w0 and -std strict_ansi options must be used (points may be deducted for failing to use the compiler and options specified).

The second line (p2 < prima...) is a way to run the p2 program and redirect input (<) to come from the primary.input file (instead of the keyboard) and have the output redirected (>) to the file my.output (instead of the screen).

The third and final line (diff -bwi ...) is how we will test to make sure that your output (my.output) matches the expected output (primary.output). The diff command will print to the screen any lines in your file that do NOT match with the corresponding lines in the other file - if nothing gets displayed that is good news - it means that your output matches the expected output. The -bwi options tell the diff command to ignore case (be case-insensitive) and to ignore extra blank spaces. You should strive to have your output diff with the primary.output without the -bwi options, as that forces you to have a "more perfect" match - however when grading we will always use the -bwi option.

In the posting account, in the ~fjm14001/Projects/P1/ directory, there are the following files (and possibly others):

     main.cpp        AMember.h       DLL.h       DataManager.h   

When we test your project we will compile it as follows:

%  make  p2

%  make

IT IS VERY STRONGLY RECOMMENDED THAT YOU ATTEMPT TO SUBMIT THIS (and every) PROJECT AT LEAST ONE FULL DAY (24-hours) IN ADVANCE. In particular no extensions will be granted for problems encountered in trying to get your program to submit unless there is an error that the majority of students encounter with the submit program we provide and/or the corresponding instructions. Additionally you should make a safe backup copy of all your work PRIOR to beginning the process to submit your project (as described below).

For this project you must "tar" and submit the following files (primarily consisting of the source (.cpp) and header (.h) files used by your implementation including your makefile):

     DataManager.h    Event.cpp       Name.h          NameList.h
     DataManager.cpp  DLL.h           Name.cpp        NameList.cpp
     Event.h          DLL.cpp         main.cpp        makefile
     AMember.h        AMember.cpp     Instantiations.cpp

NOTE THAT YOUR source files (.cpp) must be named the same as the corresponding header files (.h) - so for example the source file corresponding to Event.h must be named Event.cpp (which is just Event.h with the .h replaced by the .cpp).

WARNING - BE VERY CAREFUL USING THE UNIX TAR COMMAND - if you use the command incorrectly it may automatically DELETE (permanently) one or more of your files. Make a backup copy of your files before running the tar command. In particular the filename IMMEDIATELY after the -cvf in the tar command, must be the name of the file that you want to CREATE and put the other files into. If that file already exists it (the tar command) will automatically DELETE it and create a new one and if the file doesn't exist tar will just create a new one. To find out more about the tar command there is a "tutorial" in the posting account in the ~fjm14001/Tutorials/ directory also you can type "man tar" at the UNIX prompt to read the man page.

DO NOT EDIT YOUR TARFILE - it turns out that a tar file is a plain text file that you can read, but it may look "weird" inside - that is the way the tar file works and if you modify the tar file IT WILL NOT WORK ANYMORE and we will not be able to test your program.

After you have created the tar file you must then turn in (or submit) that file to us. The way that you do this is that you can type:

%  submit  proj2.tar  2

The submit command will generally display information to the screen and you should read that information to make sure your project submits successfully - if you do not see a message stating that your project was submitted then you should assume that it did not get submitted.

We will not accept projects submitted in any other way.

You may submit a project more than once - note however that only the last file you submit will be used for grading purposes - meaning that if you submit twice ontime and then once two days late only the last submission will be graded (the two day late version in this case). See the course syllabus for other details regarding late submissions.

NOTE: you should make a backup copy of all of your work on a regular basis. We will not grant extensions due to mistakenly deleted files or individual computer troubles. It is also recommended that if you do work and store your files on a personal computer you regularly backup those files by copying them into your class account (at least once a day during any of the days you work on your files).

DOUBLE CHECK WHAT YOU SUBMITTED to make sure that it is correct - in particular create a subdirectory and copy the file you submitted into that subdirectory and then untar it (tar -xvf) and check the contents to make sure they are correct - in particular compile and test the files that were extracted from the tar file. If there is a problem with the tar file you should fix it and try again.