Destructors should always be declared as virtual to make sure that the appropriate destructor is called.

Since it really doesn't make sense to implement this function, we could declare it as a pure virtual function as follows:

A pure virtual function should not be implemented. It serves to provide an interface for derived classes that would share this common function. The derived classes would then be required to implement this function.

One consequence of declaring a member function as pure virtual is that it now doesn't make sense to have objects from this class (since at least one of their member functions has not been implemented). In fact, it is not possible to create objects from a class that contains at least one pure virtual member function. Such a class is called an abstract base class.

By passing in a pointer to a DesktopItem we can in effect pass any type of object whose class inherits the DesktopItem class.

The protected member function add() that takes a list of pointers will be used by a number of other member functions. By creating this member function we eliminate duplicate code that would have existed in different member functions. For example, both the copy constructor and the assignment operator add items to the current object. Rather than writing the same code in each member function, we will call the add() function. This makes our implementation easier to read and maintain (changes only need to be made once). They are declared as protected member functions since they are designed to be used only by other member fuctions of the Folder class (and perhaps class that inherit the Folder class).

Here we have just one list to keep track of all different kinds of desktop items. Since a DesktopItem* can point to DesktopItem, TextFile, and Folder objects, we can keep track of all of these in one list.

Even more significantly, if we were to create additional classes that describe other kinds of desktop items (e.g., XMLFile, MSWordFile, MP3File, MSExcelFile, LaserPrinter, etc...), they could all be added to a Folder object without needing to modify the Folder class implementation at all! (This assumes that each of these additional classes inherits the DesktopItem class.)

This one seemed to give some trouble to my students, so let's step back a bit before we try to tackle this. Let's first consider the constructor for the DesktopItem class. When a DesktopItem object is instantiated (supposing one could be), the constructor is called. Each data member in the initializer list is created by passing the arguments given in the initializer list to the constructor for the object's class. Each data member that is not in the initializer list is created using its default constructor. Once all of the data members have been created, the body of the constructor is executed.

Now let's consider the behavior for a constructor of a derived class (like TextFile). In addition to initializing all of the data members, all of the data members inherited from the base class are created by calling the constructor from the base class. If the base class constructor is explicitly listed in the initializer list, the constructor is called with the given parameters. Otherwise, the default constructor for the base class is called in order to instantiate all of the data members that were inherited from the base class.

In this example, we call the constructor for the DesktopItem class explicitly in the initializer list. This sets the itemName data member to the value of name. It is worth noting that we need to make this call explicitly. Can you see what would go wrong if we didn't call it this way?

In the previous constructor, the initializer list called the DesktopItem::DesktopItem(const string& name) constructor. In this initializer list we are calling the DesktopItem::DesktopItem(const DesktopItem& old) constructor. The interesting thing here is that while the constructor takes a reference to a DesktopItem, we are really passing a reference to a TextFile.

Generally speaking, we have forced a derived class object to "look like" a base class object. This is known as upcasting, and it is perfectly legal since the base class knows (at least partially) what the derived class object can do. However, the base class only knows about the stuff in the derived class that was inherited from the base class. Therefore, any additional members (data or functions) that were defined in the derived class are not available to old in the DesktopItem constructor. This loss of data is known as object slicing. In this case, the fact that we have lost data associated with rhs when passing to the DesktopItem constructor should not concern us because we are relying on the DesktopItem constructor only to take care of the data members inherited from the DesktopItem class. The second item in the initializer list takes care of copying the text data member.

Before we move on, let's consider the following alternate implementation of the copy constructor:

In this case we do not explicitly call the DesktopItem copy constructor, instead, the default constructor from the DesktopItem class is implicitly called before the TextFile constructor is executed. As a result, we need to set the value of the itemName data member within the body of the TextFile constructor. It turns out that this implementation is not legal for the same reason we had to call the DesktopItem constructor in the previous constructor implementation. Did you figure out why it wouldn't work above? In both cases we have to have an explicit call to a DesktopItem constructor because the default constructor for the DesktopItem class is private (and therefore, not available to the TextFile class). It should also be noted that placing itemName(rhs.itemName) in the initializer list will cause a compile error. Why do you think this results in an error?

Just as the DesktopItem constructor was implicitly called in the alternate implementation of the copy constructor, the DesktopItem destructor is implicitly called. The destructor for the parent class is called immediately following the completion of the destructor from the derived class.

It is worth noting that we have made an explicit call to the assignment operator from the DesktopItem class. We did not need to do it this way. In fact, it may have been easier to just say itemName = rhs.itemName; instead. However, making explicit use of the functions from the base class (both here and in the constructors) means that if the DesktopItem class is enhanced to include additional data members/member functions (e.g., we could add a data member to keep track of the time the file was created) the TextFile constructors and assignment operator would not require modification because we are relying on the member functions from the DesktopItem to handle any data members associated with the DesktopItem class.

The clone function dynamically allocates a copy of the calling TextFile object and returns a pointer to it. See more discussion on how this function is useful in the Folder class.

Why do you suppose this function was declared a pure virtual function in the DesktopItem class? Hint: It was declared pure virtual because it is not possible to implement it in the DesktopItem class. Why couldn't we implement it in the DesktopItem class?

As with the TextFile copy constructor, we explicitly call the DesktopItem copy constructor to handle all of the data members associated with the DesktopItem class (itemName). In addition, we need to make a copy of all of the items in the list of desktop items from rhs. Since desktopItems is a list of pointers, we need to do more than just copy the list (copying the list would just give us copies of the pointers, but the pointers would be pointing to exactly the same TextFile and Folder objects that the original list pointed to. Instead, we want to make a copy of each object and add a pointer to the new list that points to the newly created object. This is all done by the protected add() member function.

We actually have something to do in the destructor this time. Remember that the desktopItems data member is a list of pointers. The objects that the elements of the list point to are dynamically allocated using the new operator. Therefore, we need to delete them before we destroy the list of pointers. (If we did not do this, we would have a massive memory leak because each object pointed to by an element of the list would now be lost, but the memory associated with the object would not be recovered.) All of this work is done in the erase() member function.

Here it is critical that we check of self-assignment (A=A). The reason this is critical is that if we did not, all the items in the folder would be lost anytime a folder was assigned to itself. Can you see why?

Much like the assignment operator of the TextFile class, we make use of the assignment operator from the DesktopItem class to take care of the data members inherited from the DesktopItem class. We then erase the old list (deallocating the memory for each object to avoid memory leaks), and then add the elements from the list in rhs.

This function loops through all of the elements in the folder (the list of DesktopItem* called desktopItems) until it finds an item with a matching name or reaches the end of the list. If no match was found, the if statement below is executed. It calls the appropriate version of the clone member function (using polymorphism, it looks to see what type of object item is pointing to and calls the version of the function from that class. It then pushs the pointer to the newly created object onto the end of the list.

If an item in the folder has an itemName that matches name, the item is removed from the folder. This is done by first deallocating the memory associated with the object and then removing the pointer to it from the list.

What does this do if we have a folder of 9 folders where each folder is 1 MB big and a text file that is 1 MB big? Does it return a size of approximately 1 MB or approximately 10 MB? How do you know?