Due: 10/11/01

This programming assignment is designed to:

• Introduce inheritence
• Review function overloading
• Introduce virtual functions

NOTE ON THE USE OF PREVIOUS FILES - you MAY simply extend the capabilities of assignment #7. If you used the number 7 in the name, that's OK; just be sure to clearly label it as number 8 in your file header comments.

• No new buttons need to be added to the interface.
• One new EditBox should be added to the interface for user Input; i.e. you will need one of type CString for entering Names and a 2nd one of type int for entering Ages.
• Each Insert will store a Name AND an Age in a strData object and then pass the address of that object to List::Insert.
• Each Find will expect a Name AND an Age to be supplied and will look for an identical Name/Age in the list. What is probably less than obvious is that OnButtonFind will need to
  1. create a strData object,
  2. pass its address to List::Find,
  3. get back a true or false, and then
  4. delete the object that was create in #1.
• The Display() function will continue to use List::Reset(), List::GetNext() and List::EOL(). Since GetNext() returns a Node * (a pointer which is really pointing to a strData object), Display() will need to
  1. cast the pointer to be a strData * type
  2. concatenate the Name and the Age in the strData object and
  3. addstring the concatenated string to the ListBox, so that it looks something like
  4. Jim Johnson (24)

The following changes should be made to the Classes and functions from assignment #7.

• In the List class
  • Everywhere that a function expected to receive a CString argument should be changed to expect an arguement of type Node*
  • None of the List:: functions should ever use the function new. The button functions will be responsible for BOTH allocating new objects and for deleting them when appropriate.
  • SPECIAL NOTE: The List object is defined so that mHead and mTail think that they point to 'Nodes'. Through the use of inheritence they really point to strData objects. Most of the time the List member functions are only working with a location so they don't really care how much data is stored at that location - the Button functions created the strData objects and most of the time the Button functions will delete those objects. The exception occurs when you exit your project with Nodes remaining in the List. In this situation it is up to the List::~List() destructor to 'cleanup' the remaining items in the List. The destructor moves down the list delete-ing each Node which is really a strData object. This will work correctly if you give Node a virtual destructor as shown below
  • Modify the Find(Node * ) function so that the part that does the comparison looks like
    • if( *current == *argument)
  • Modify GetNext() to return a Node *; i.e. an actual pointer to the next Node.
• In the Node class
  • Remove any declaration of user data. The Node will only be declared to contain next and prev.
  • Add the function
    • virtual bool operator==(Node &) = 0;

    • virtual ~Node()        //inline the virtual destructor
      {}                     //no body is required

• Define a new class/struct in the ...Dlg class 
  struct strData:public Node 
  { 
  	CString mName; 
  	int mAge; 
  	bool operator(Node &);
     ~strData()            //inline the destructor
      {}                   //no body is required
  }
  

• bool strData::operator==(Node & arg) 
  {
  if( the-name-in-this-node == the-name-in-the-arg-node AND
      the-age-in-this-node == the-age-in-the-arg-node )
    return true;
  else
    return false;
  }
  

Programming aid:

In the operator== function above you receive an argument OBJECT 
(not a location of an object) of declared type Node when in fact 
it is of type strData. When you know this you can safely cast it 
to the correct type in a couple ways.
   ((strData &)arg).mName    Think of this as saying, you received
                             a Node by reference - now think of it
                             as being a strData by reference and I
                             want the mName field contained within
OR
 ((strData *) (&arg)) -> mName  Give me the memory location of the
                                object that was passed in (arg);
                                now think of that as being the location
                                of an strData object and I want the
                                mName field contained within

Always, given a pointer, P, to SomeObj that contains a field SomeFld
you have the following choices for getting at the SomeFld field

P->SomeFld
(*P).SomeFld

Or the reverse, given the name (X) of SomeObj that contains a field SomeFld
you have the following choices for getting at the SomeFld field

X.SomeFld
(&X)->SomeFld