Last Modified: Fri Nov 19 16:58:24 EST 2004
|
C M S C 2 1 4 C o m p u t e r S c i e n c e II F a l l 2 0 0 4 |
No. In particular the DLL and BST (variables inside the DataManager class) must remain as they are and you can not modify them.
There is probably a problem with the BST or DLL code somewhere - in particular you should examine EVERY line of code of your BST class (or DLL class) to make sure that it is correct "POLYMORPHIC CODE".
So what does it mean, "POLYMORPHIC CODE"? Polymorphic code is code that is designed to work with base class POINTERS or REFERENCES and never create an actual base object (as a local variable or passed in by value).
To check your BST code you should examine every line of code that uses BSTData and check to see if it is actually creating a POINTER or a REFERENCE or a VARIABLE - if it is a POINTER or REFERENCE then it is very good whereas if it is a VARIABLE then it is probably bad. For example you should modify any/every function in the BST class that passes in a BSTData object by value INTO one that passes in a BSTData object BY CONST-REFERENCE - you are permitted to make this type of change.
Also note that the duplicate (aka "clone") function can be very useful (particularly in the ADD function). Think about POLYMORPHISM and what this means and draw very detailed pictures and trace through the code and hopefully you'll find where the problem(s) may be.
Similar things will work for the DLL class - look for DLLData everywhere and make sure you do not create any VARIABLES of type DLLData, but instead you should have pointers and/or references of type DLLData.
Note that it is possible to call a base ctor - but remember that the only (correct) way to do so is in the MEMBER INITIALIZER LIST - the member initializer list is a VERY USEFUL THING and should always be considered when writing a ctor.
Also note that the copy ctor ALWAYS exists as does the OPERATOR= - no matter what - if you do not write one the "auto-generated" one IS created (and is public by default). Thus if you are writing the op= (assignment operator) for a derived class and want to "safely" "assign" the base stuff, you can do so by calling the base's op= function inside the derived op= function (how do you call a base function? Use the scope resolution operator and the NAME of the base function - so what is the name of the op= function? It is operator= and can be called like that).
Side note: In section 11 of the project description it mentions that the print forward/backward for Events should do "All", "TimedEvent" and "TeamEvent" and then in section 12 it states you should be able to do "All", "Event", "TimedEvent" and "TeamEvent" (the primary input requires you to be able to do "Event"). Thus you should be able to do all 4 (for the AMember related stuff there is only three possibilities - "All", "Athlete" or "Coach").
So how do you print just the right type of objects? For the DLL stuff you can just use an ITERATOR and go through the list and if it is "the right type of thing" print it, otherwise skip it.
For the BST stuff if you have the ITERATOR done then you can do the same thing - if not see below.
So how do you tell if it is "the right type of thing"? There are many ways - you can try a dynamic_cast (this is the WORST way), you can try to use typeid (better but not the best way) or you can try to use the classType() member function (which is public) - this is the best way (for this project).
So how do you do the Event stuff (with the BST) if you didn't do the BST ITERATOR (which was extra credit) - in this case you will have to modify the BST printForward (and printBackward) public member functions so that they take in a C++ string which specifies the type of object to print out - you are permitted to make this modification to the BST printForward and printBackward functions (you may NOT make this modification to the DLL printForward/Backward).
No. You can assume the team names for a single event will be unique - meaning there will not be two teams with the same name competing in the same event.
Yes and no. The project specification DOES permit you to write your own protected and/or private helping functions for the Event and the AMember classes. For at least one of these classes you probably will want to add one or more protected helping functions.
The project specification does not say much about private/protected "helping functions" for the 4 derived classes (TimedEvent, TeamEvent, Athlete or Coach) HOWEVER you CAN add both private and protected helping functions to these 4 derived classes as you feel necessary.
Yep, by mistake there was a missing semi-colon on line 33 of main.cpp - it has been corrected in the file in the posting account and if you haven't found it yet you should correct the copy of the main.cpp you copied out of the posting account. This should be an easy bug to find/fix.
You should follow the functions/code as they are written in the "header files" (when there is a discrepancy with the project description) and so your function should be named "getExhibition" (for the TeamEvent class).
It turns out that or is indeed a reserved word now in C++ - this is a relatively new thing and some compilers do not "enforce" this yet HOWEVER the cxx and g++ compilers on the dc.umd.edu network do "enforce" the or keyword (and thus the TimedEvent.h file will not compile).
So, you should change the "or" data member of TimedEvent to be "OR" (capital O and capital R) - the TimedEvent_interface file has been corrected to reflect this now.
Yes. As for how, the original header files (Event.h and AMember.h) were incorrect and the readin and writeout methods were supposed to be protected (not private - since there is no way to use them in the derived classes if they are private). The two header files in the posting account have been FIXED and now the derived classes can use the readin/writeout methods found in the base (if you copied the Event.h and AMember.h files before this change you should re-copy them).
Also note that the project description does permit you to write your own protected and private methods for most of the classes (note however that very few, if any, are needed).
Although all 4 interfaces are very similar it is important to read through all 4 of them as well as the other posted files in the P4 directory of the posting account. Note that you should copy (using the Unix "cp" command) the posted files (ESPECIALLY THE .h FILES) into your account and use those ones and NOT the ones you submitted for project #3.
Project #4 is due 2 days before Thanksgiving Break. See the syllabus for complete details, but in short, note that you must submit a working project #4 implementation in order to pass CMSC 214. If after the 2 day late period for project #4 you have not been able to submit the project, contact the instructor via email for assistance.
The last day to submit project #4 is Friday, December 10th by 11pm and any project #4 submitted after the 2 day late period will receive at most 25 points (and at least 10 points).
Project #4 is due by 11PM on Tuesday, November 23rd, 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: Fri Nov 19 16:58:24 EST 2004 |
|
|
|
|
|