Hunter Liu's Website

17. Week 10 Tuesday: Destructors and Friends

This set of notes is not so much a focused discussion or presentation of a single topic, but rather a sparse collection of loosely related topics from lecture that we haven’t had a chance to talk about yet. It’s a little less in depth than usual — there are only so many hours in a day, and the rate at which I produce these notes is unfortunately finite.

Destructors

Remember that objects are just variables whose type is a class or a struct. In the musical chairs problem from last week, the players in the game were all objects. Likewise, variables of type string or vector are all objects.

The lifetime of an object is as follows:

1. The object is declared — the computer allocates and reserves some memory for this variable, then gives it to the program to use.
2. The object is initialised — the memory is filled with useful information (i.e., all the private member variables are set up). This is where the constructor gets run.
3. The object is used throughout the program.
4. The object’s destructor is run.
5. The object’s memory is returned to the computer so it can be used by another program later.

Steps 1 and 2 are always run together, one right after another. Once the program receives a chunk of memory to use from the computer, it uses the constructor from a class to put that memory to use.

Steps 4 and 5 are always run together as well. Just before an object is destroyed, a special function called the destructor is run. If no destructor is provided, then nothing is done and it skips ahead to step 5.

A destructor is similar to a constructor — it is not allowed to have a return type, and its name needs to match the name of the struct or class. To distinguish it from the constructor, it is preceeded by a tilde (~). However, destructors are not allowed to take any parameters; they cannot be called explicitly by the program.

Here is a simple example involving a minimal class with one variable that demonstrates a few different scenarios in which objects get destroyed:

 1#include <iostream>
 2#include <string> 
 3
 4using namespace std; 
 5
 6class person {
 7private: 
 8    string name; 
 9
10public: 
11    // constructor - makes a person with the given name 
12    person(string new_name) {
13        name = new_name; 
14    } 
15
16    // destructor - prints out the name of the person 
17    // getting "destroyed"
18    ~person() {
19        cout << name << " has been obliterated." << endl; 
20    }
21}; 
22
23void foo() {
24    person mildred("mildred"); 
25} 
26
27int main() {
28    person timothy("timothy"); 
29
30    if(true) {
31        person pete("pete"); 
32    }
33
34    int counter = 0; 
35    while(true) {
36        person simon("simon"); 
37
38        if(counter >= 3) {
39            break; 
40        }
41
42        counter++; 
43    }
44
45    foo(); 
46
47    return 0; 
48}

You will find that pete gets obliterated first, then simon gets obliterated four times, then mildred gets obliterated, and finally timothy gets obliterated. This demonstrates the following scenarios in which a destructor gets called:

• At the end of an if block (or an else if block, or an else block), any variables that were declared within that block are destroyed.
• At the end of each iteration of a loop, any variables defined within the loop are destroyed.
• At the end of any function (including the main function), any variables declared within the function are destroyed.

Friends

As you may have encountered, having private variables in a class can be very, very cumbersome to code with. This is really for your own safety, as well as for other programmers’ safety, but there are some rare situations wherein this private barrier acts as a legitimate to writing proper and efficient code. These situations, unfortunately, are somewhat beyond the scope of our class. In general, you should stick to keeping your variables private and only exposing access through public functions.

As a reminder, private members are invisible to anything outside of the class, including other functions, other classes, and the main function. Attempting to access them will produce a compile error.

The friend keyword is a way around this, and it specifies classes outside the current class that are allowed to access the private members directly. Let’s provide a very simple example. Here are two classes representing a parent and a child.

 1class child {
 2private: 
 3    string name; 
 4
 5public: 
 6    child(string new_name) {
 7        name = new_name; 
 8    }
 9
10    string get_name() {
11        return name; 
12    }
13}; 
14
15class parent {
16private:
17    string name; 
18    child offspring; 
19
20public: 
21    parent(string new_name, new_offspring) {
22        name = new_name; 
23        offspring = new_offspring; 
24    } 
25
26    string get_name() {
27        return name; 
28    }
29
30    child get_offspring() {
31        return offspring; 
32    }
33};

In these class definitions, each child has nothing but a name. The child class has a constructor that takes a name as an argument, and it has one public function to retrieve its name. Similarly, the parent class holds a name and an offspring, and I’ll let you figure out what the public member functions do.

Suppose, for some reason, we wanted to allow parent to change the name of their offspring. Certainly, one approach is to write a void rename(string new_name); function under the public section of the child class. However, it’s possible that you don’t want the entire world to be able to change children’s names; how can you make it only possible for parents to change their child’s name?

We can turn the parent into a friend of the child, thereby granting the parent access to the private name variable in the child class. Then, we can write a function in the parent class that changes the name of their offspring.

 1class child {
 2private: 
 3    string name; 
 4
 5    friend class parent; // grants the parent class access! 
 6
 7public: 
 8    child(string new_name) {
 9        name = new_name; 
10    }
11
12    string get_name() {
13        return name; 
14    }
15}; 
16
17class parent {
18private:
19    string name; 
20    child offspring; 
21
22public: 
23    parent(string new_name, new_offspring) {
24        name = new_name; 
25        offspring = new_offspring; 
26    } 
27
28    string get_name() {
29        return name; 
30    }
31
32    child get_offspring() {
33        return offspring; 
34    }
35
36    // renames the offspring! 
37    void rename_offspring(string new_name) {
38        offspring.name = new_name; 
39    }
40};

Line 5 grants the parent class the right to change anything in the private section of the child class, including the name. Lines 37-39 define a function for a parent to rename their child! Importantly, line 38 is now valid because of line 5.

Here’s an example of how the main function might look:

1int main() {
2    child c("Billy"); 
3    parent p("Bill", c); 
4    p.rename_child("Bilbo"); 
5
6    cout << c.get_name() << endl; 
7    cout << p.get_offspring().get_name() << endl; 
8    return 0; 
9}

What is the output? Why is the output like that? This outcome is probably somewhat surprising and unintuitive. If you’ve already learned about pointers, this is a good opportunity to try to fix the output so that it matches our expectations!

Some cautions: first, your friend’s friends are not your friends. If you have 3 classes, say A, B, and C, and if C is a friend of B and B is a friend of A, then C is not immediately a friend of A. Wow, that’s a lot. The point is, if C can access B’s private variables, and if B can access A’s private variables, C may not be able to access A’s private variables — you can’t “chain” friends together like that.

Second, you can put a friend declaration anywhere in a class declaration. It doesn’t matter if it’s private or public (or even neither)!

A Practise Problem

You are likely bogged down with the homework assignments, but here’s a practise problem designed to help you get the hang of object-oriented programming. These do not necessarily use destructors or the friend keyword! If you can’t think of a reason to use them, you probably don’t need to.

The most important thing for me is the design; you don’t actually have to go through and code it up. Think about what class(es) you’ll have to write, what kind of private variables they should store, and what public functions should be available.