• I'm having trouble creating the Instantiation.cpp file. [10/09/04]
• [msg] The Due Date for Project #2 has been extended 2 days.
• [msg] IMPORTANT - The best way to create DLL.h

• Do we have to do the extra credit from project #1? [10/06/04]
• What is printPartMembersSal?

• Do we have to use the memtracker tool to find memory problems in our code? [10/05/04]
• Do we have to templatize the doubly-linked list?
• [msg] Primary input/output posted READ THIS

• [msg] Visual Studio won't compile the AMember.h file. [10/04/04]
• Has the AMember.h file been changed?

• When is Project #2 due? [09/29/04]

List of Answers to FAQ

• I'm having trouble creating the Instantiations.cpp file.

  Note that the instantiation file when done properly for this project will be very short (not counting the #includes it could be somewhere between 2 to 10 lines long). Also note that you should NOT #include a .cpp file in any other file besides the instantiation file otherwise you may lose points. Finally note that the instantiation file for this project must be named Instantiations.cpp and you will only be instantiating classes (not individual member functions - when you instantiate a class it instantiates all the code for that class - which is what you want done).

  If you are having difficultly getting your instantiation file to work then in the worst case scenario do not do it - cxx does "magic instantiation" and thus you do not need an instantiation file and your program should still be able to submit even if you do not get the instantiation file working. You will lose at most 5 points for not having an instantiation file (on future projects you may lose more points).

  An easy way to tell if your instantiation file is not complete/correct (since cxx tends to do the "magic instantiation" automatically) is to use the g++ compiler (this is just a quick way to check - we will not check your file this way) as follows:

  % cp p2.tar SomeDirectory
  % cd SomeDirectory
  % tar -xvf p2.tar
  % g++ *.cpp
  

  And if there are no compiler error messages then chances are your instantiation file is correct. If there are compiler error messages they might be from instantiation problems and you should inspect them, HOWEVER if you make any changes MAKE SURE THEY WORK with the cxx compiler before you resubmit (you should only be doing this check if you have lots of time left or you have already submitted your project).

• [msg] The Due Date for Project #2 has been extended 2 days.

  In order to allow students ample time to study for Exam 1 the due date for project #2 has been extended 2 days. Thus project #2 is now due on THURSDAY, October 14th by 11pm. NOTE HOWEVER that if you do turn in project #2 by the original due date (Tuesday, Oct. 12 by 11pm) and you do not turn in a project after that time then you will receive an automatic 15 point bonus (extra credit) - for a possible grade of 115 on the project.

  DO NOT LET THIS DISTRACT YOU FROM GETTING PROJECT #2 DONE and TURNED IN ONTIME. If you do not have project #2 passing the primary yet then it is STRONGLY RECOMMENDED you KEEP WORKING ON PROJECT #2 as much as possible at this time and manage the time you have left on it well.

• [msg] IMPORTANT - The best way to create DLL.h

  First off - the "IMPORTANT" part should not be necessary - it is expected that students READ ALL FAQS POSTED (definitely prior to asking any questions). In particular several students have not read the FAQ below with "READ THIS" in the description line and have been coming in asking the very question answered in that short FAQ below.

  As for the point of this FAQ - you have to write PART of the DLL.h file and how you do this MAY BE GRADED. Note that you should follow the following guidelines when creating your DLL.h file - even if you have submitted the project already you may lose points if your DLL.h file does not follow these rules (which may have been explicit or implicitly assumed in the original project description):

  1. USE THE DLL.h file provided in the posting account (it is best to not type it in from scratch).
  2. You should ONLY MAKE THE FOLLOWING CHANGES TO THE DLL.h file provided:
     • Add any #include's necessary for the header file and they must appear in the spot stated in the file.
     • Do not modify the DLLNode or DLLIter classes at all. Meaning do not add anything or remove anything or move anything.
     • Put in the "body" of the DLL class definition - when doing this use the EventList class (found in the EventList.h file from project #1) as a guideline. IN PARTICULAR YOU SHOULD PUT THE PROTOTYPES FOR THE DLL MEMBER FUNCTIONS IN THE ***EXACT*** ORDER AS THEY APPEAR IN THE EVENTLIST CLASS. Meaning the default ctor should be first, then the copy ctor, then op=, then the dtor, then isEmpty(), then ...
     • For the names of the parameter variables (found in the function prototypes) either leave them as they were in project #1 or else remove them. If you choose to remove them do so from ALL of the prototypes of the member functions.
     • You can add any private member functions (no data members) you want and the three private member functions found in project #1 are optional. You may also add comments to this header file, however you do not have to do so and it is requested that you do not.
  If you follow those guidelines then chances are that your DLL.h will not be "flagged" for review and if it is flagged for review then chances are it may lose points.

• Do we have to do the extra credit from project #1?

  No. You do not have to do it and it won't be tested. Thus the two secondaries (in3 and in4) that test these extra credit parts will not be used when we test project #2.

  However if you have time it wouldn't hurt to do the extra credit part if you didn't in project #1, unfortunately we will not be able to give you any extra credit for doing so (it was a one time offer good on project #1 only).

• What is printPartMembersSal?

  This was a "typo" that appeared twice in the "Additional Info" section under the description of the DataManager class. It was supposed to be printPartMembersYears and thus you can replace the printPartMembersSal with printPartMembersYears.

• Do we have to use the memtracker tool to find memory problems in our code?

  It is highly recommended that you use this tool at least once on each project you submit, but probably as follows:

  1. If you have tried all other means to track down a memory related problem and they are unsuccessful - then try this memtracker tool (both with level 1 tracking and then if necessary with level 2 tracking). See the README found in the posting account for how to use this tool (and the section near the bottom about the "special version" - which is level 2 tracking).
  2. After you have submitted your project you should run the memtracker tool to see if there are any memory problems with your code - and if there are you should try to fix them and resubmit if possible. Note that if you turned something in ontime and then found and fixed a problem - using memtracker - a day later (so now it would be 1 day late) you need to make the decision to determine how severe you think that problem was and if you need to resubmit - if we do not find that problem in our "normal" testing (testing without the use of the memtracker tool) then more than likely it will NOT be worth it to resubmit late - however if we could find that problem in "normal" testing then it may be worth it to resubmit the fixed program.
  3. We may use the memtracker tool to determine if a program has memory management problems and a small amount of points (no more than 10 on project #2) may be deducted based off errors we find in code through the use of the memtracker program.

  NOTE that the memtracker tool modifies your code automatically and replaces every occurence of the word "new " with "new(214) " as this is needed in order for the memtracker tool to determine if the system libraries are having memory problems or if it is your code. Because of this, you may notice (very rarely) small problems when compiling with the memtracker tool - in particular if a variable name ends in "new" (for example if you had a variable named "renew") then it might not compile - change the name of the variable and it should work. Do not modify your code to try to "fool" our memtracker program and note that most of the time no changes to your code should be needed at all - and if some changes are needed, you will get a compiler error that should specify which file/line needs to be fixed.

• Do we have to templatize the doubly-linked list?

  Yes. Although you could make a few minor changes to your project #1 and it would "pass the submit program", if you have not removed the EventList class completely from your code and replaced it with a templatized DLL, you will receive a 0 (zero) on this project even though it may "pass the submit program".

• [msg] Primary input/output posted READ THIS

  The primary input/output files for the project have been posted and submit will now accept submissions. Note the following items:

  1. The primary.output has the <amember_out> ending with an <endl> which was not in the original project description. You do need to have a new line (endl) printed by the AMember operator>> function in order for your code to submit. Thus you should consider this notice that the BNF for <amember_out> is now officially changed so that a single new line (endl) appears at the end of it.
  2. Several secondary outputs have been posted as well - most of them (1 through 4) are nearly identical to those posted in project #1. The fifth secondary input/output demonstrates how the PRINAMESYEAR option should work. In particular note that if the current year is 2004 and we want to print out all the members who have been members for 10 or more years then only those members (for the event in question) who have been members since 1994 or earlier will be printed. The names of the members printed out should be in the order in which they are found in the participants list.

• [msg] Visual Studio won't compile the AMember.h file.

  If you are using Visual Studio to compile your project you will have to modify the AMember.h file as described here. In particular, Visual Studio says that it is a compiler error to initialize a CONST STATIC data member the way that it is done in the AMember.h file (it should not be an error, but Visual Studio doesn't like it). The way to fix this problem is to change it so that you initialize the CUR_YEAR *after* the class declaration, near the bottom of the AMember.h file. NOTE: YOU ONLY HAVE TO DO THIS IF YOU ARE USING VISUAL STUDIO. If you submit a project that has been modified as described here you will not lose any points - just make sure it compiles and runs on the class cluster using cxx and the -w0 and -std strict_ansi options.

• Has the AMember.h file been changed?

  Yes. The AMember.h file changed very slightly. It was originally posted on 9/29/04 around 6:15pm, and it was updated on 10/01/04 around 12:30pm and has not changed since then. The two changes that were made were:

  1. The year_in parameter for the AMember ctor was originally a float variable - this has been changed and it is now an int variable.
  2. There was no easy "public" way to access the private static data member (CUR_YEAR). A public static member function named getCurYear was added and it should just return the CUR_YEAR (by value). Note that this function is not const because it can not be made const - it is a STATIC member function. You should implement this function.

• When is Project #2 due?

  Project #1 is due by 11PM on Tuesday, October 12th, 2004. Note: any project may be turned in late up to 2 days as specified on the class syllabus. For details regarding the late policy and any penalties associated with submitting late projects please see the class syllabus.

See the class syllabus for policies concerning email Last Modified: Sat Oct 9 12:23:32 EDT 2004