ICS 45C Spring 2022, Notes and Examples: Well-Behaved Classes

Background

As we've talked about previously, C++ classes provide a way to define new data types. There is no deep distinction between user-defined types and built-in types. We can build our own types to have all of the same flexibility and expressiveness that the various built-in types have. Additionally, classes do not automatically introduce extra cost into our program — in terms of memory or time — unless we do things with them that introduce that cost. They do, however, provide a design win: the ability to encapsulate a set of data along with a set of operations that can safely manipulate that data. It's often the case in programming that we have to trade away some performance in order to achieve design clarity; C++ classes (if we use them carefully) allow us to have both.

However, in order to use C++ classes effectively, it becomes necessary to do a few things that will seem foreign if you've seen classes in most of the other programming languages that offer them. As usual, C++ gives us more knobs that we can turn to control efficiency and design flexibility, at the cost of additional complexity. And, in some cases, turning those knobs appropriately is paramount not only for achieving performance, but also for achieving correctness. So we don't want to get much farther down the path of learning C++ without being sure we understand how to write classes that are what I call "well-behaved."

What is a "well-behaved" class?

This example explores how to build what I call a "well-behaved" class. The term "well-behaved" is a little bit loose, but here are some things that objects of a well-behaved class do.

The statically-allocated portion of them is compact enough that it is possible to store objects of a well-behaved class on the run-time stack, so we can get the benefit of their automatically deletion when they fall out of scope. If these objects manage large amounts of memory, it's dynamically-allocated by the object behind the scenes.
They clean up after themselves automatically when they die, meaning that deleting an object is all that needs to be done to ensure that no other resources (memory, open files, etc.) associated with that object have leaked.
They can be passed to functions by value and preserve the usual semantics (i.e., changing the object within the function does not have any effect on the original). In cases where this doesn't make sense, this should be disallowed altogether, rather than silently behaving badly.
They can be assigned into existing objects of the same type, with the appropriate copying and cleanup, again, done automatically. In cases where this doesn't make sense, this should be disallowed altogether, rather than silently behaving badly.
They can be const, while preserving the ability to perform all operations that do not violate the promise of const. In other words, operations that do not change the publicly observable state of the object are legal; those that do potentially change it are illegal.
They shouldn't do unnecessary work or use memory or other resources unnecessarily; they should be efficient. (Note that the term "unnecessarily" is in the eye of the beholder; the goal isn't always to be absolutely as fast as possible, when that goal trades off against other desirable properties like readability, maintainability, or separation of concerns.)

The std::string class in the C++ standard library has these properties, so we can expect it to be as clean and easy-to-use as an int — albeit potentially slower to work with, since string operations like concatenation obviously take more time than, say, integer addition. We should want the same for our classes.

Our ArrayList class

In this example, we explore an ArrayList class, which very roughly parallels the behavior of a class built into the C++ standard library (which we'll explore in detail relatively soon) called std::vector. Our ArrayList is an array-based list. It stores a sequence of elements, indexed consecutively starting at zero, providing constant-time access to any element given its index. Unlike an array, though, our ArrayList provides a few conveniences.

It handles all of the necessary dynamic array allocation and deallocation. At any given time, an ArrayList contains one dynamically-allocated array.
It keeps track of the capacity of the underlying array, as well as tracking how many elements are currently being stored in the list (which we'll call the ArrayList's size). If there are n elements stored in the list, they will always occupy the first n cells of the underlying array, but the underlying array may have additional empty space available.
As elements are added and the underlying array fills, the ArrayList allocates a new array and copies existing elements into it, so there is no theoretical limit on the number of elements that can be stored (though there is obviously a practical limit, since machines only have so much memory).

Being well-behaved, we expect to be able to do many things with our ArrayList once it's built, without having to worry too much about confusing, error-prone details. We should expect to be able to:

Allocate ArrayLists statically or dynamically.
Add elements to ArrayLists without worrying about running out of space (because of the array reallocations that are done internally when the arrays fill).
Pass ArrayLists by value or by reference, while preserving the appropriate semantics.
Declare const ArrayLists, whose elements we can read but not write.

These are the things we want to achieve. In order to get there, though, we'll need to learn some features of C++ that we haven't seen yet.

"The Big Three"

Classes whose objects manage resources that live outside of themselves — such as dynamically-allocated memory, open files, open connections to networks, etc. — generally require three new kinds of functions to be implemented.

A destructor. We've seen previously that constructors are called just after an object is created; their job is to initialize the newly-created object. Destructors are called just before an object's death, and they perform whatever cleanup is necessary (aside from the destruction of the member variables, which is handled automatically).
A copy constructor, which is used to initialize new objects that are created as copies of existing ones (e.g., because an object has been passed by value, or because one object has been used to explicitly initialize another).
An assignment operator, which is called every time an existing object is assigned into another existing object. Note that this is distinct from what a copy constructor does; copy constructors initialize newly-created objects, while the assignment operator is invoked when you have two objects already and one is being assigned into the other.

These three functions, together, are sometimes called The Big Three, because the need to write one of them usually implies the need to write all three of them, and because they play a vital role in allowing many kinds of objects to manage resources properly.

Not all classes require the Big Three, because defaults are generated if you don't write them. Any class whose member variables are all of well-behaved classes will generally work just fine, because the defaults are sensible in that case:

By default, destroying an object destroys its member variables. Constructors initialize member variables in the order they're listed in the class declaration, just before the body of the constructor is executed. Destructors destroy them in the opposite order, just after the body of the destructor is executed. A default destructor has an empty body, meaning that the only thing destroyed are the member variables. But if those member variables are all well-behaved, they clean up any necessary resources automatically when they die, so there's nothing else the destructor needs to do.
By default, creating a copy of an object copies its member variables, one by one, into the new object. If those member variables are all well-behaved, they support the appropriate copying semantics already, so nothing special needs to be done.
By default, assigning an object assigns its member variables one by one from the source object into the target object, in place of the original member variables in the target object. If those member variables are well-behaved, they support assignment already.

Most of the built-in types in C++ can be thought of as well-behaved. Pointers are worth thinking about carefully, though, because it's important to understand that destroying a pointer doesn't destroy what the pointer points to, nor does copying a pointer copy what it points to. For this reason, our ArrayList class requires the Big Three, because the dynamically-allocated arrays require manual management — we'll manually create them with the new operator and destroy them with delete[ ]. Placing that manual memory management (mostly) into the Big Three means that code that uses our ArrayList class can remain blissfully unaware of these details, while still achieving the kind of performance it could achieve by managing the arrays itself. That's a big win indeed.

A couple of additional notes

I've introduced a couple of additional twists here that we didn't cover in lecture; these are things we'll see again later, but they fit nicely into this example, so I've extended it to include them.

Note, also, that the Big Three became the Big Five in the C++11 standard, because of the inclusion of a new feature called moving. I left that out of this example for the sake of simplicity, but moving does offer a significant performance optimization for some kinds of objects. We may see the tools for this — move constructors and move assignment operators — later in this course, but we'll wait on them for now; all things in time.

The code

Writing well-behaved classes requires some care, and the accompanying code for this example tries to take as much of that care as possible. Be sure you read through both the code and the associated comments; we'll be relying on your understanding of these details as we go forward from here.

The official moniker for this code example is WellBehavedClasses, so your best bet is to do this:

Create a new project using the example project template.
Change into the project directory.
Issue the command ./download WellBehavedClasses to download the code example into your project directory's app directory.

Alternatively, you can click the link to the tarball below:

WellBehavedClasses.tar.gz