• If we do NOT do the extra credit, do we have to write the
  findEventsOf or ... or findEventsSameVenue member
  functions in DataManager? [11/01/04]
• Can I use a "fancy" add or delete?
• Do I have to keep the shape when copying?

• How can I find memory leaks? [10/31/04]

• When is Project #3 due? [10/16/04]

List of Answers to FAQ

• If we do NOT do the extra credit, do we have to write the findEventsOf or ... or findEventsSameVenue member functions in from DataManager?

  No. If you DO implement the extra credit you should (but do not have to) write/implement these functions. Note in particular that the findEventsOf, the findEventsBetYear, the findVenueSchedule, and the findEventsSameVenue functions all require that you have some way to "iterate" through the BST - and if you do NOT do the extra credit then you have no way to do this - and thus you do NOT have to implement this functionality (meaning you do not have to implement the four functions described here).

• Can I use a "fancy" add or delete?

  No. You should use the "basic" BST insert discussed in lecture and the "basic" BST remove discussed in lecture. Note that for the BST remove, in the case of a node with 2 children, there are four possible ways to do the remove - choose any one of those four methods (left subtree predecessor, right subtree successor, easy left subtree pullup or easy right subtree pullup) and your program will be fine and will receive full credit for this part. A "fancy" insert or delete would be one that would try to "reshape" the tree to make it as short as possible - later in the semester we will discuss a variation of a BST to do this (many exist) but you should not try to do this on this project.

• Do I have to keep the shape when copying?

  Yes. For full credit your copy ctor and your operator= should make "copies" of the tree and the shape of those copies should be the same (meaning "printTree" would print out the same tree).

• How can I find memory leaks?

  This FAQ is assuming that the memory leak was detected by the memtracker program (which is a program written only for CMSC 214 and is not a program you can find anywhere else - however there are other related programs available on other systems and on Unix systems). If you do not know how to use the memtracker program read the following text file in the POSTING account:

  ~fjm14001/MemoryTool/README.memoryTracker
  

  Note that when using the tool copy all *.h and *.cpp files into the directory and then run "memtracker" on it:

  % mkdir TEST
  % cp *.h *.cpp TEST
  % memtracker TEST
  ...
  % a.out < input > output
  ... and then check the output
  

  So now what happens when a leak is detected? It only gets reported at the END of the program - the hard part is finding where that memory was created (and then should have been deleted). IF YOU ARE USING THE PRIMARY INPUT/OUTPUT this MAY be very hard to find. HOWEVER, if you create your own TEST FILES which test SPECIFIC parts of your code (and do so well) then chances are you will be able to find the leak in that code and it will be easier to find - but of course creating these TEST FILES takes time and might not find the leak (if they don't test the code well enough).

  SO ANOTHER WAY to find the leak is to re-run the memtracker tool but this time do level 2 detection. NOTE THAT WHEN YOU DO THIS lots of extra output may be produced HOWEVER the extra output can be used to find out WHEN (and then eventually WHERE) in your code the memory is created. In particular with "level 2" detection the memtracker tool prints out a message EVERY TIME new is called (it prints out the address of the memory space created) and every time delete is called (printing out the address of the memory space deleted). To run memtracker with "level 2" detection put a 2 at the end like this:

  % memtracker TEST 2
  

  And that will create an a.out with level 2 detection turned on. At the end of the program the memory that has been "leaked" is the memory that was never deleted - and when reporting the leak the ADDRESS of the space "leaked" is printed (and thus if you look earlier in the output you should be able to find where that memory was created with the new command - and thus find where the leak started).

  This can be a challenging process to track down a "bug" like this, but it is bugs like these that cause the programs that you buy and run on your computers to crash.

• When is Project #3 due?

  Project #3 is due by 11PM on Thursday, November 4th, 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: Mon Nov 1 17:13:02 EST 2004