A meaningful exercise that requires using a destructor

Question

I am teaching destructors in C++ and would like to give the students an interesting homework exercise that requires them to build a class with destructor.

In previous years, the homework were something like "write a linked list, but do not use the classes in the STL". I do not like this - I tell my students that they can use whatever feature of the language that they want, even if we did not learn it in class yet.

The problem is, for every other exercise that I could think of (e.g, tree, graph, etc.) I could easily think of a solution using STL features, that does not require any destructor.

What is an interesting exercise where destructors are really needed?

Answer 1

Create an object that creates a new file and writes in to it over several method invocations (not just one). Assure that the object has been deleted before continuing (Make the object go out of scope on the stack or delete a reference and let the reference go out of scope.) You need to assure that he file was closed. The destructor is the proper place to assure that this happens.

To verify that it works correctly, create a different object that reads from the file. If the first object didn't properly close the file this won't be possible.

In some, at least, operating systems you don't even need the second part. The file won't appear in the file system if it was never closed.

The reason for wanting the file written over several invocations of some method(s) is that, if it is just one, an explicit close would be natural in that method. The reason for wanting any references to go out of scope is to assure you that the first object has no effect on the second.

---

Edited for clarification.

Answer 2

There are 2 good examples of patterns where the destuctor is a key.
This way you can teach a couple of useful patterns on the way.

RAII - Resource Acquisition Is Initiation

Rule of 3/5/0

It's easy to give a RAII assignment, just any C style handle that can be released in the end (Like a File handle, windows handle, etc).

If they are more advanced, you can try and teach about shared pointer implementation and have them attempt that (which could get tricky if you want to go into thread safety, etc.

Answer 3

I'm not a native of C++, but it seems to me that a Conway's Game of Life simulator, with cells as immutable objects, would be a great way to show the need for a destructor. Without one, your program would quickly run out of memory.

And, of course, it's not a bad approach to the problem. All you'd have to do to demonstrate why such an approach is reasonable is to first try the naive approach of modifying the active gameboard to figure out the next turn. This, of course, always leads to incorrect behaviors, since the modification of one cell will be used in the calculation of the next cell.

One final advantage is that you will also be introducing your students to an important and interesting other algorithm in its own right.

Answer 4

A separate approach entirely from my other answer is to code the main method of a project yourself, but ask your students to build the classes that will make your main method accomplish its task. This actually opens back up projects like linked lists, as your main will use a slightly different spec than the natural C++ library in any case.

Just include calls to the destructors of the classes when appropriate, and your project will quite naturally require destructors. And if your project requires any substantial amount of composition, failure to use destructors properly across the project will cause the program to run out of memory. Thus, you will be modeling the need first by directly calling destructors, and secondarily in a way that causes them to see the need themselves, with the students having to both design and call the relevant destructors for objects held through composition.

Answer 5

OK, here is an idea.

Write a class Member that keeps track of members in a social network. Each member can follow/unfollow other members and know how many people he/she follows/followed by. Additionally the system keeps track of the number of active members.

Here is a sample main program:

Member avi, beni, chana;

void test1() {
    Member dana;
    chana.follow(dana);
    dana.follow(avi);
    cout << "  " << chana.numFollowers() << " " <<  chana.numFollowing() << endl; // 0 1
    cout << "  " << avi.numFollowers() << " " <<  avi.numFollowing() << endl; // 1 0
    cout << "  " << Member::count() << endl; // 4
}

int main() {
    cout << chana.numFollowers() << " " <<  chana.numFollowing() << endl; // 0 0
    test1();
    cout << chana.numFollowers() << " " <<  chana.numFollowing() << endl; // 0 0
    cout << avi.numFollowers() << " " <<  avi.numFollowing() << endl; // 0 0
    cout << Member::count() << endl; // 3
}

What do you think?