The Spreadsheet Class

Chapter 8 introduces the SpreadsheetCell class. This chapter moves on to write the Spreadsheet class. As with the SpreadsheetCell class, the Spreadsheet class evolves throughout this chapter. Thus, the various attempts do not always illustrate the best way to do every aspect of class writing. To start, a Spreadsheet is simply a two-dimensional array of SpreadsheetCells, with methods to set and retrieve cells at specific locations in the Spreadsheet. Although most spreadsheet applications use letters in one direction and numbers in the other to refer to cells, this Spreadsheet uses numbers in both directions. Here is a first attempt at a class definition for a simple Spreadsheet class:

#include <cstddef>
#include "SpreadsheetCell.h"

class Spreadsheet
{
    public:
        Spreadsheet(size_t width, size_t height);
        void setCellAt(size_t x, size_t y, const SpreadsheetCell& cell);
        SpreadsheetCell& getCellAt(size_t x, size_t y);
    private:
        bool inRange(size_t value, size_t upper) const;
        size_t mWidth = 0;
        size_t mHeight = 0;
        SpreadsheetCell** mCells = nullptr;
};

Note that the Spreadsheet class does not contain a standard two-dimensional array of SpreadsheetCells. Instead, it contains a SpreadsheetCell**. This is because each Spreadsheet object might have different dimensions, so the constructor of the class must dynamically allocate the two-dimensional array based on the client-specified height and width. In order to allocate dynamically a two-dimensional array, you need to write the following code. Note that in C++, unlike in Java, it’s not possible to simply write new SpreadsheetCell[mWidth][mHeight].

Spreadsheet::Spreadsheet(size_t width, size_t height)
    : mWidth(width), mHeight(height)
{
    mCells = new SpreadsheetCell*[mWidth];
    for (size_t i = 0; i < mWidth; i++) {
        mCells[i] = new SpreadsheetCell[mHeight];
    }
}

The resulting memory for a Spreadsheet called s1 on the stack with width 4 and height 3 is shown in Figure 9-1.

The implementations of the set and retrieval methods are straightforward:

void Spreadsheet::setCellAt(size_t x, size_t y, const SpreadsheetCell& cell)
{
    if (!inRange(x, mWidth) || !inRange(y, mHeight)) {
        throw std::out_of_range("");
    }
    mCells[x][y] = cell;
}

SpreadsheetCell& Spreadsheet::getCellAt(size_t x, size_t y)
{
    if (!inRange(x, mWidth) || !inRange(y, mHeight)) {
        throw std::out_of_range("");
    }
    return mCells[x][y];
}

Note that these two methods use a helper method inRange() to check that x and y represent valid coordinates in the spreadsheet. Attempting to access an array element at an out-of-range index will cause the program to malfunction. This example uses exceptions, which are mentioned in Chapter 1 and described in detail in Chapter 14.

If you look at the setCellAt() and getCellAt() methods, you see there is some clear code duplication. Chapter 6 explains that code duplication should be avoided at all costs. So, let’s follow that guideline. Instead of a helper method called inRange(), the following verifyCoordinate() method is defined for the class:

void verifyCoordinate(size_t x, size_t y) const;

The implementation checks the given coordinate and throws an exception if the coordinate is invalid:

void Spreadsheet::verifyCoordinate(size_t x, size_t y) const
{
    if (x >= mWidth || y >= mHeight) {
        throw std::out_of_range("");
    }
}

The setCellAt() and getCellAt() methods can now be simplified:

void Spreadsheet::setCellAt(size_t x, size_t y, const SpreadsheetCell& cell)
{
    verifyCoordinate(x, y);
    mCells[x][y] = cell;
}

SpreadsheetCell& Spreadsheet::getCellAt(size_t x, size_t y)
{
    verifyCoordinate(x, y);
    return mCells[x][y];
}

Freeing Memory with Destructors

Whenever you are finished with dynamically allocated memory, you should free it. If you dynamically allocate memory in an object, the place to free that memory is in the destructor. The compiler guarantees that the destructor is called when the object is destroyed. Here is the Spreadsheet class definition with a destructor:

class Spreadsheet
{
    public:
        Spreadsheet(size_t width, size_t height);
        ~Spreadsheet();
        // Code omitted for brevity
};

The destructor has the same name as the name of the class (and of the constructors), preceded by a tilde (~). The destructor takes no arguments, and there can only be one of them. Destructors are implicitly marked as noexcept, since they should not throw any exceptions.

Here is the implementation of the Spreadsheet class destructor:

Spreadsheet::~Spreadsheet()
{
    for (size_t i = 0; i < mWidth; i++) {
        delete [] mCells[i];
    }
    delete [] mCells;
    mCells = nullptr;
}

This destructor frees the memory that was allocated in the constructor. However, no rule requires you to free memory in the destructor. You can write whatever code you want in the destructor, but it is a good idea to use it only for freeing memory or disposing of other resources.

Handling Copying and Assignment

Recall from Chapter 8 that if you don’t write a copy constructor and an assignment operator yourself, C++ writes them for you. These compiler-generated methods recursively call the copy constructor or assignment operator on object data members. However, for primitives, such as int, double, and pointers, they provide shallow or bitwise copying or assignment: they just copy or assign the data members from the source object directly to the destination object. That presents problems when you dynamically allocate memory in your object. For example, the following code copies the spreadsheet s1 to initialize s when s1 is passed to the printSpreadsheet() function:

#include "Spreadsheet.h"

void printSpreadsheet(Spreadsheet s)
{
   // Code omitted for brevity.
}

int main()
{
    Spreadsheet s1(4, 3);
    printSpreadsheet(s1);
    return 0;
}

The Spreadsheet contains one pointer variable: mCells. A shallow copy of a spreadsheet gives the destination object a copy of the mCells pointer, but not a copy of the underlying data. Thus, you end up with a situation where both s and s1 have a pointer to the same data, as shown in Figure 9-2.

If s changes something to which mCells points, that change shows up in s1 too. Even worse, when the printSpreadsheet() function exits, s’s destructor is called, which frees the memory pointed to by mCells. That leaves the situation shown in Figure 9-3.

Now s1 has a pointer that no longer points to valid memory. This is called a dangling pointer.

Unbelievably, the problem is even worse with assignment. Suppose that you have the following code:

Spreadsheet s1(2, 2), s2(4, 3);
s1 = s2;

After the first line, when both objects are constructed, you have the memory layout shown in Figure 9-4.

After the assignment statement, you have the layout shown in Figure 9-5.

Now, not only do the mCells pointers in s1 and s2 point to the same memory, but you have also orphaned the memory to which mCells in s1 previously pointed. This is called a memory leak. That is why in assignment operators you must do a deep copy.

As you can see, relying on C++’s default copy constructor and default assignment operator is not always a good idea.

class Spreadsheet
{
    public:
        Spreadsheet(const Spreadsheet& src);
        // Code omitted for brevity
};

Spreadsheet::Spreadsheet(const Spreadsheet& src)
    : Spreadsheet(src.mWidth, src.mHeight)
{
    for (size_t i = 0; i < mWidth; i++) {
        for (size_t j = 0; j < mHeight; j++) {
            mCells[i][j] = src.mCells[i][j];
        }
    }
}

class Spreadsheet
{
    public:
        Spreadsheet& operator=(const Spreadsheet& rhs);
        // Code omitted for brevity
};

Spreadsheet& Spreadsheet::operator=(const Spreadsheet& rhs)
{
    // Check for self-assignment
    if (this == &rhs) {
        return *this;
    }

    // Free the old memory
    for (size_t i = 0; i < mWidth; i++) {
        delete[] mCells[i];
    }
    delete[] mCells;
    mCells = nullptr;

    // Allocate new memory
    mWidth = rhs.mWidth;
    mHeight = rhs.mHeight;

    mCells = new SpreadsheetCell*[mWidth];
    for (size_t i = 0; i < mWidth; i++) {
        mCells[i] = new SpreadsheetCell[mHeight];
    }

    // Copy the data
    for (size_t i = 0; i < mWidth; i++) {
        for (size_t j = 0; j < mHeight; j++) {
            mCells[i][j] = rhs.mCells[i][j];
        }
    }

    return *this;
}

class Spreadsheet
{
    public:
        Spreadsheet& operator=(const Spreadsheet& rhs);
        friend void swap(Spreadsheet& first, Spreadsheet& second) noexcept;
        // Code omitted for brevity
};

void swap(Spreadsheet& first, Spreadsheet& second) noexcept
{
    using std::swap;

    swap(first.mWidth, second.mWidth);
    swap(first.mHeight, second.mHeight);
    swap(first.mCells, second.mCells);
}

Spreadsheet& Spreadsheet::operator=(const Spreadsheet& rhs)
{
    // Check for self-assignment
    if (this == &rhs) {
        return *this;
    }

    Spreadsheet temp(rhs); // Do all the work in a temporary instance
    swap(*this, temp); // Commit the work with only non-throwing operations
    return *this;
}

class Spreadsheet
{
    public:
        Spreadsheet(size_t width, size_t height);
        Spreadsheet(const Spreadsheet& src) = delete;
        ~Spreadsheet();
        Spreadsheet& operator=(const Spreadsheet& rhs) = delete;
        // Code omitted for brevity
};

'Spreadsheet &Spreadsheet::operator =(const Spreadsheet &)' : attempting to reference a deleted function 

Handling Moving with Move Semantics

Move semantics for objects requires a move constructor and a move assignment operator. These can be used by the compiler when the source object is a temporary object that will be destroyed after the operation is finished. Both the move constructor and the move assignment operator move the data members from the source object to the new object, leaving the source object in some valid but otherwise indeterminate state. Often, data members of the source object are reset to null values. This process actually moves ownership of the memory and other resources from one object to another object. They basically do a shallow copy of the member variables, and switch ownership of allocated memory and other resources to prevent dangling pointers or resources, and to prevent memory leaks.

Before you can implement move semantics, you need to learn about rvalues and rvalue references.

int a = 4 * 2;

// lvalue reference parameter
void handleMessage(std::string& message)
{
    cout << "handleMessage with lvalue reference: " << message << endl;
}

// rvalue reference parameter
void handleMessage(std::string&& message)
{
    cout << "handleMessage with rvalue reference: " << message << endl;
}

std::string a = "Hello ";
std::string b = "World";
handleMessage(a);             // Calls handleMessage(string& value)

handleMessage(a + b);         // Calls handleMessage(string&& value)

handleMessage("Hello World"); // Calls handleMessage(string&& value)

handleMessage(std::move(b));  // Calls handleMessage(string&& value)

void helper(std::string&& message)
{
}

void handleMessage(std::string&& message)
{
    helper(message);
}

void handleMessage(std::string&& message)
{
    helper(std::move(message));
}

int& i = 2;       // Invalid: reference to a constant
int a = 2, b = 3;
int& j = a + b;   // Invalid: reference to a temporary

int&& i = 2;
int a = 2, b = 3;
int&& j = a + b;

class Spreadsheet
{
    public:
        Spreadsheet(Spreadsheet&& src) noexcept; // Move constructor
        Spreadsheet& operator=(Spreadsheet&& rhs) noexcept; // Move assign
        // Remaining code omitted for brevity
    private:
        void cleanup() noexcept;
        void moveFrom(Spreadsheet& src) noexcept;
        // Remaining code omitted for brevity
};

void Spreadsheet::cleanup() noexcept
{
    for (size_t i = 0; i < mWidth; i++) {
        delete[] mCells[i];
    }
    delete[] mCells;
    mCells = nullptr;
    mWidth = mHeight = 0;
}

void Spreadsheet::moveFrom(Spreadsheet& src) noexcept
{
    // Shallow copy of data
    mWidth = src.mWidth;
    mHeight = src.mHeight;
    mCells = src.mCells;

    // Reset the source object, because ownership has been moved!
    src.mWidth = 0;
    src.mHeight = 0;
    src.mCells = nullptr;
}

// Move constructor
Spreadsheet::Spreadsheet(Spreadsheet&& src) noexcept
{
    moveFrom(src);
}

// Move assignment operator
Spreadsheet& Spreadsheet::operator=(Spreadsheet&& rhs) noexcept
{
    // check for self-assignment
    if (this == &rhs) {
        return *this;
    }

    // free the old memory
    cleanup();

    moveFrom(rhs);

    return *this;
}

void Spreadsheet::moveFrom(Spreadsheet& src) noexcept
{
    // Move object data members
    mName = std::move(src.mName);

    // Move primitives:
    // Shallow copy of data
    mWidth = src.mWidth;
    mHeight = src.mHeight;
    mCells = src.mCells;

    // Reset the source object, because ownership has been moved!
    src.mWidth = 0;
    src.mHeight = 0;
    src.mCells = nullptr;
}

class Spreadsheet
{
    private:
        Spreadsheet() = default;
        // Remaining code omitted for brevity
};

Spreadsheet::Spreadsheet(Spreadsheet&& src) noexcept
    : Spreadsheet()
{
    swap(*this, src);
}

Spreadsheet& Spreadsheet::operator=(Spreadsheet&& rhs) noexcept
{
    Spreadsheet temp(std::move(rhs));
    swap(*this, temp);
    return *this;
}

Spreadsheet createObject()
{
    return Spreadsheet(3, 2);
}

int main()
{
    vector<Spreadsheet> vec;
    for (int i = 0; i < 2; ++i) {
        cout << "Iteration " << i << endl;
        vec.push_back(Spreadsheet(100, 100));
        cout << endl;
    }

    Spreadsheet s(2,3);
    s = createObject();

    Spreadsheet s2(5,6);
    s2 = s;
    return 0;
}

Iteration 0
Normal constructor         (1)
Move constructor           (2)

Iteration 1
Normal constructor         (3)
Move constructor           (4)
Move constructor           (5)

Normal constructor         (6)
Normal constructor         (7)
Move assignment operator   (8)
Normal constructor         (9)
Copy assignment operator  (10)
Normal constructor        (11)
Copy constructor          (12)

vec.push_back(Spreadsheet(100, 100));

void swapCopy(T& a, T& b)
{
    T temp(a);
    a = b;
    b = temp;
}

void swapMove(T& a, T& b)
{
    T temp(std::move(a));
    a = std::move(b);
    b = std::move(temp);
}

Rule of Zero

Earlier in this chapter, the rule of five was introduced. All the discussions so far have been to explain how you have to write those five special member functions: destructor, copy and move constructors, and copy and move assignment operators. However, in modern C++, you should adopt the so-called rule of zero.

The rule of zero states that you should design your classes in such a way that they do not require any of those five special member functions. How do you do that? Basically, you should avoid having any old-style dynamically allocated memory. Instead, use modern constructs such as Standard Library containers. For example, use a vector<vector<SpreadsheetCell>> instead of the SpreadsheetCell** data member in the Spreadsheet class. The vector handles memory automatically, so there is no need for any of those five special member functions.

static Methods

Methods, like data members, sometimes apply to the class as a whole, not to each object. You can write static methods as well as data members. As an example, consider the SpreadsheetCell class from Chapter 8. It has two helper methods: stringToDouble() and doubleToString(). These methods don’t access information about specific objects, so they could be static. Here is the class definition with these methods static:

class SpreadsheetCell
{
    // Omitted for brevity
    private:
        static std::string doubleToString(double inValue);
        static double stringToDouble(std::string_view inString);
        // Omitted for brevity
};

The implementations of these two methods are identical to the previous implementations. You don’t repeat the static keyword in front of the method definitions. However, note that static methods are not called on a specific object, so they have no this pointer, and are not executing for a specific object with access to its non-static members. In fact, a static method is just like a regular function. The only difference is that it can access private and protected static members of the class. It can also access private and protected non-static data members on objects of the same type, if those objects are made visible to the static method, for example, by passing in a reference or pointer to such an object.

You call a static method just like a regular function from within any method of the class. Thus, the implementation of all the methods in SpreadsheetCell can stay the same. Outside of the class, you need to qualify the method name with the class name using the scope resolution operator. Access control applies as usual.

You might want to make stringToDouble() and doubleToString() public so that other code outside the class can make use of them. If so, you can call them from anywhere like this:

string str = SpreadsheetCell::doubleToString(5.0);

const Methods

A const object is an object whose value cannot be changed. If you have a const, reference to const, or pointer to a const object, the compiler does not let you call any methods on that object unless those methods guarantee that they won’t change any data members. The way you guarantee that a method won’t change data members is to mark the method itself with the const keyword. Here is the SpreadsheetCell class with the methods that don’t change any data members marked as const:

class SpreadsheetCell
{
    public:
        // Omitted for brevity
        double getValue() const;
        std::string getString() const;
        // Omitted for brevity
};

The const specification is part of the method prototype and must accompany its definition as well:

double SpreadsheetCell::getValue() const
{
    return mValue;
}

std::string SpreadsheetCell::getString() const
{
    return doubleToString(mValue);
}

Marking a method as const signs a contract with client code guaranteeing that you will not change the internal values of the object within the method. If you try to declare a method const that actually modifies a data member, the compiler will complain. You also cannot declare a static method, such as the doubleToString() and stringToDouble() methods from the previous section, const because it is redundant. Static methods do not have an instance of the class, so it would be impossible for them to change internal values. const works by making it appear inside the method that you have a const reference to each data member. Thus, if you try to change the data member, the compiler will flag an error.

You can call const and non-const methods on a non-const object. However, you can only call const methods on a const object. Here are some examples:

SpreadsheetCell myCell(5);
cout << myCell.getValue() << endl;      // OK
myCell.setString("6");                  // OK

const SpreadsheetCell& myCellConstRef = myCell;
cout << myCellConstRef.getValue() << endl; // OK
myCellConstRef.setString("6");             // Compilation Error!

You should get into the habit of declaring const all methods that don’t modify the object so that you can use references to const objects in your program.

Note that const objects can still be destroyed, and their destructor can be called. Nevertheless, destructors are not allowed to be declared const.

class SpreadsheetCell
{
    // Omitted for brevity
    private:
        double mValue = 0;
        mutable size_t mNumAccesses = 0;
};

double SpreadsheetCell::getValue() const
{
    mNumAccesses++;
    return mValue;
}

std::string SpreadsheetCell::getString() const
{
    mNumAccesses++;
    return doubleToString(mValue);
}

Method Overloading

You’ve already noticed that you can write multiple constructors in a class, all of which have the same name. These constructors differ only in the number and/or types of their parameters. You can do the same thing for any method or function in C++. Specifically, you can overload the function or method name by using it for multiple functions, as long as the number and/or types of the parameters differ. For example, in the SpreadsheetCell class you can rename both setString() and setValue() to set(). The class definition now looks like this:

class SpreadsheetCell
{
    public:
        // Omitted for brevity
        void set(double inValue);
        void set(std::string_view inString);
        // Omitted for brevity
};

The implementations of the set() methods stay the same. When you write code to call set(), the compiler determines which instance to call based on the parameter you pass: if you pass a string_view, the compiler calls the string instance; if you pass a double, the compiler calls the double instance. This is called overload resolution.

You might be tempted to do the same thing for getValue() and getString(): rename each of them to get(). However, that does not work. C++ does not allow you to overload a method name based only on the return type of the method because in many cases it would be impossible for the compiler to determine which instance of the method to call. For example, if the return value of the method is not captured anywhere, the compiler has no way to tell which instance of the method you are trying to call.

class Spreadsheet
{
    public:
        SpreadsheetCell& getCellAt(size_t x, size_t y);
        const SpreadsheetCell& getCellAt(size_t x, size_t y) const;
        // Code omitted for brevity.
};

const SpreadsheetCell& Spreadsheet::getCellAt(size_t x, size_t y) const
{
    verifyCoordinate(x, y);
    return mCells[x][y];
}

SpreadsheetCell& Spreadsheet::getCellAt(size_t x, size_t y)
{
    return const_cast<SpreadsheetCell&>(std::as_const(*this).getCellAt(x, y));
}

return const_cast<SpreadsheetCell&>(
    static_cast<const Spreadsheet&>(*this).getCellAt(x, y));

Spreadsheet sheet1(5, 6);
SpreadsheetCell& cell1 = sheet1.getCellAt(1, 1);

const Spreadsheet sheet2(5, 6);
const SpreadsheetCell& cell2 = sheet2.getCellAt(1, 1);

class MyClass
{
    public:
        void foo(int i);
};

MyClass c;
c.foo(123);
c.foo(1.23);

class MyClass
{
    public:
        void foo(int i);
        void foo(double d) = delete;
};

Inline Methods

C++ gives you the ability to recommend that a call to a method (or function) should not actually be implemented in the generated code as a call to a separate block of code. Instead, the compiler should insert the method’s body directly into the code where the method is called. This process is called inlining, and methods that want this behavior are called inline methods. Inlining is safer than using #define macros.

You can specify an inline method by placing the inline keyword in front of its name in the method definition. For example, you might want to make the accessor methods of the SpreadsheetCell class inline, in which case you would define them like this:

inline double SpreadsheetCell::getValue() const
{
    mNumAccesses++;
    return mValue;
}

inline std::string SpreadsheetCell::getString() const
{
    mNumAccesses++;
    return doubleToString(mValue);
}

This gives a hint to the compiler to replace calls to getValue() and getString() with the actual method body instead of generating code to make a function call. Note that the inline keyword is just a hint for the compiler. The compiler can ignore it if it thinks it would hurt performance.

There is one caveat: definitions of inline methods (and functions) must be available in every source file in which they are called. That makes sense if you think about it: how can the compiler substitute the method’s body if it can’t see the method definition? Thus, if you write inline methods, you should place the definitions in a header file along with their prototypes.

C++ provides an alternate syntax for declaring inline methods that doesn’t use the inline keyword at all. Instead, you place the method definition directly in the class definition. Here is a SpreadsheetCell class definition with this syntax:

class SpreadsheetCell
{
    public:
        // Omitted for brevity
        double getValue() const { mNumAccesses++; return mValue; }

        std::string getString() const
        {
            mNumAccesses++;
            return doubleToString(mValue);
        }
        // Omitted for brevity
};

Many C++ programmers discover the inline method syntax and employ it without understanding the ramifications of marking a method inline. Marking a method or function as inline only gives a hint to the compiler. Compilers will only inline the simplest methods and functions. If you define an inline method that the compiler doesn’t want to inline, it will silently ignore the hint. Modern compilers will take metrics like code bloat into account before deciding to inline a method or function, and they will not inline anything that is not cost-effective.

Default Arguments

A feature similar to method overloading in C++ is default arguments. You can specify defaults for function and method parameters in the prototype. If the user specifies those arguments, the default values are ignored. If the user omits those arguments, the default values are used. There is a limitation, though: you can only provide defaults for a continuous list of parameters starting from the rightmost parameter. Otherwise, the compiler will not be able to match missing arguments to default arguments. Default arguments can be used in functions, methods, and constructors. For example, you can assign default values to the width and height in your Spreadsheet constructor:

class Spreadsheet
{
    public:
        Spreadsheet(size_t width = 100, size_t height = 100);
        // Omitted for brevity
};

The implementation of the Spreadsheet constructor stays the same. Note that you specify the default arguments only in the method declaration, but not in the definition.

Now you can call the Spreadsheet constructor with zero, one, or two, arguments even though there is only one non-copy constructor:

Spreadsheet s1;
Spreadsheet s2(5);
Spreadsheet s3(5, 6);

A constructor with defaults for all its parameters can function as a default constructor. That is, you can construct an object of that class without specifying any arguments. If you try to declare both a default constructor and a multi-argument constructor with defaults for all its parameters, the compiler will complain because it won’t know which constructor to call if you don’t specify any arguments.

Note that anything you can do with default arguments you can do with method overloading. You could write three different constructors, each of which takes a different number of parameters. However, default arguments allow you to write just one constructor that can take three different number of arguments. You should use the mechanism with which you are most comfortable.

static Data Members

Sometimes giving each object of a class a copy of a variable is overkill or won’t work. The data member might be specific to the class, but not appropriate for each object to have its own copy. For example, you might want to give each spreadsheet a unique numerical identifier. You would need a counter that starts at 0 from which each new object could obtain its ID. This spreadsheet counter really belongs to the Spreadsheet class, but it doesn’t make sense for each Spreadsheet object to have a copy of it because you would have to keep all the counters synchronized somehow. C++ provides a solution with static data members. A static data member is a data member associated with a class instead of an object. You can think of static data members as global variables specific to a class. Here is the Spreadsheet class definition, including the new static counter data member:

class Spreadsheet
{
    // Omitted for brevity
    private:
        static size_t sCounter;
};

In addition to listing static class members in the class definition, you will have to allocate space for them in a source file, usually the source file in which you place your class method definitions. You can initialize them at the same time, but note that unlike normal variables and data members, they are initialized to 0 by default. Static pointers are initialized to nullptr. Here is the code to allocate space for, and zero-initialize, the sCounter member:

size_t Spreadsheet::sCounter;

Static data members are zero-initialized by default, but if you want, you can explicitly initialize them to 0 as follows:

size_t Spreadsheet::sCounter = 0;

This code appears outside of any function or method bodies. It’s almost like declaring a global variable, except that the Spreadsheet:: scope resolution specifies that it’s part of the Spreadsheet class.

class Spreadsheet
{
    // Omitted for brevity
    private:
        static inline size_t sCounter = 0;
};

size_t Spreadsheet::sCounter;

class Spreadsheet
{
    public:
        // Omitted for brevity 
        size_t getId() const;
    private:
        // Omitted for brevity
        static size_t sCounter;
        size_t mId = 0;
};

Spreadsheet::Spreadsheet(size_t width, size_t height)
    : mId(sCounter++), mWidth(width), mHeight(height)
{
    mCells = new SpreadsheetCell*[mWidth];
    for (size_t i = 0; i < mWidth; i++) {
        mCells[i] = new SpreadsheetCell[mHeight];
    }
}

int c = Spreadsheet::sCounter;

const static Data Members

Data members in your class can be declared const, meaning they can’t be changed after they are created and initialized. You should use static const (or const static) data members in place of global constants when the constants apply only to the class, also called class constants. static const data members of integral and enumeration types can be defined and initialized inside the class definition without making them inline variables. For example, you might want to specify a maximum height and width for spreadsheets. If the user tries to construct a spreadsheet with a greater height or width than the maximum, the maximum is used instead. You can make the maximum height and width static const members of the Spreadsheet class:

class Spreadsheet
{
    public:
        // Omitted for brevity
        static const size_t kMaxHeight = 100;
        static const size_t kMaxWidth = 100;
};

You can use these new constants in your constructor as follows:

Spreadsheet::Spreadsheet(size_t width, size_t height)
    : mId(sCounter++)
    , mWidth(std::min(width, kMaxWidth))// std::min() requires <algorithm>
    , mHeight(std::min(height, kMaxHeight))
{
    mCells = new SpreadsheetCell*[mWidth];
    for (size_t i = 0; i < mWidth; i++) {
        mCells[i] = new SpreadsheetCell[mHeight];
    }
}

kMaxHeight and kMaxWidth are public, so you can access them from anywhere in your program as if they were global variables, but with slightly different syntax. You must specify that the variable is part of the Spreadsheet class with the :: scope resolution operator:

cout << "Maximum height is: " << Spreadsheet::kMaxHeight << endl;

These constants can also be used as default values for the constructor parameters. Remember that you can only give default values for a continuous set of parameters starting with the rightmost parameter:

class Spreadsheet
{
    public:
        Spreadsheet(size_t width = kMaxWidth, size_t height = kMaxHeight);
        // Omitted for brevity
};

Reference Data Members

Spreadsheets and SpreadsheetCells are great, but they don’t make a very useful application by themselves. You need code to control the entire spreadsheet program, which you could package into a SpreadsheetApplication class.

The implementation of this class is unimportant at the moment. For now, consider this architecture problem: how can spreadsheets communicate with the application? The application stores a list of spreadsheets, so it can communicate with the spreadsheets. Similarly, each spreadsheet could store a reference to the application object. The Spreadsheet class must then know about the SpreadsheetApplication class, and the SpreadsheetApplication class must know about the Spreadsheet class. This is a circular reference and cannot be solved with normal #includes. The solution is to use a forward declaration in one of the header files. The following is a new Spreadsheet class definition that uses a forward declaration to tell the compiler about the SpreadsheetApplication class. Chapter 11 explains another benefit of forward declarations: they can improve compilation and linking times.

class SpreadsheetApplication; // forward declaration

class Spreadsheet
{
    public:
        Spreadsheet(size_t width, size_t height,
            SpreadsheetApplication& theApp);
        // Code omitted for brevity.
    private:
        // Code omitted for brevity.
        SpreadsheetApplication& mTheApp;
};

This definition adds a SpreadsheetApplication reference as a data member. It’s recommended to use a reference in this case instead of a pointer because a Spreadsheet should always refer to a SpreadsheetApplication. This would not be guaranteed with a pointer.

Note that storing a reference to the application is only done to demonstrate the use of references as data members. It’s not recommended to couple the Spreadsheet and SpreadsheetApplication classes together in this way, but instead to use a paradigm such as MVC (Model-View-Controller), introduced in Chapter 4.

The application reference is given to each Spreadsheet in its constructor. A reference cannot exist without referring to something, so mTheApp must be given a value in the ctor-initializer of the constructor:

Spreadsheet::Spreadsheet(size_t width, size_t height,
    SpreadsheetApplication& theApp)
    : mId(sCounter++)
    , mWidth(std::min(width, kMaxWidth))
    , mHeight(std::min(height, kMaxHeight))
    , mTheApp(theApp)
{
    // Code omitted for brevity.
}

You must also initialize the reference member in the copy constructor. This is handled automatically because the Spreadsheet copy constructor delegates to the non-copy constructor, which initializes the reference member.

Remember that after you have initialized a reference, you cannot change the object to which it refers. It’s not possible to assign to references in the assignment operator. Depending on your use case, this might mean that an assignment operator cannot be provided for your class with reference data members. If that’s the case, the assignment operator is typically marked as deleted.

const Reference Data Members

Your reference members can refer to const objects just as normal references can refer to const objects. For example, you might decide that Spreadsheets should only have a const reference to the application object. You can simply change the class definition to declare mTheApp as a const reference:

class Spreadsheet
{
    public:
        Spreadsheet(size_t width, size_t height,
            const SpreadsheetApplication& theApp);
            // Code omitted for brevity.
    private:
            // Code omitted for brevity.
            const SpreadsheetApplication& mTheApp;
};

There is an important difference between using a const reference versus a non-const reference. The const reference SpreadsheetApplication data member can only be used to call const methods on the SpreadsheetApplication object. If you try to call a non-const method through a const reference, you will get a compilation error.

It’s also possible to have a static reference member or a static const reference member, but you will rarely need something like that.

Example: Implementing Addition for SpreadsheetCells

In true object-oriented fashion, SpreadsheetCell objects should be able to add themselves to other SpreadsheetCell objects. Adding a cell to another cell produces a third cell with the result. It doesn’t change either of the original cells. The meaning of addition for SpreadsheetCells is the addition of the values of the cells.

class SpreadsheetCell
{
    public:
        // Omitted for brevity
         SpreadsheetCell add(const SpreadsheetCell& cell) const;
        // Omitted for brevity
};

SpreadsheetCell SpreadsheetCell::add(const SpreadsheetCell& cell) const
{
    return SpreadsheetCell(getValue() + cell.getValue());
}

SpreadsheetCell myCell(4), anotherCell(5);
SpreadsheetCell aThirdCell = myCell.add(anotherCell);

SpreadsheetCell myCell(4), anotherCell(5);
SpreadsheetCell aThirdCell = myCell + anotherCell;

class SpreadsheetCell
{
    public:
        // Omitted for brevity
         SpreadsheetCell operator+(const SpreadsheetCell& cell) const;
        // Omitted for brevity
};

SpreadsheetCell SpreadsheetCell::operator+(const SpreadsheetCell& cell) const
{
    return SpreadsheetCell(getValue() + cell.getValue());
}

SpreadsheetCell aThirdCell = myCell + anotherCell;

SpreadsheetCell aThirdCell = myCell.operator+(anotherCell);

SpreadsheetCell myCell(4), aThirdCell;
string str = "hello";
aThirdCell = myCell + string_view(str);
aThirdCell = myCell + 5.6;
aThirdCell = myCell + 4;

class SpreadsheetCell
{
    public:
        SpreadsheetCell() = default;
        SpreadsheetCell(double initialValue);
        explicit SpreadsheetCell(std::string_view initialValue);
    // Remainder omitted for brevity
};

SpreadsheetCell SpreadsheetCell::operator+(double rhs) const
{
    return SpreadsheetCell(getValue() + rhs);
}

aThirdCell = myCell + 4;   // Works fine.
aThirdCell = myCell + 5.6; // Works fine.
aThirdCell = 4 + myCell;   // FAILS TO COMPILE!
aThirdCell = 5.6 + myCell; // FAILS TO COMPILE!

SpreadsheetCell operator+(const SpreadsheetCell& lhs,
    const SpreadsheetCell& rhs)
{
    return SpreadsheetCell(lhs.getValue() + rhs.getValue());    
}

class SpreadsheetCell
{
    //Omitted for brevity
};

SpreadsheetCell operator+(const SpreadsheetCell& lhs,
    const SpreadsheetCell& rhs);

aThirdCell = myCell + 4;   // Works fine.
aThirdCell = myCell + 5.6; // Works fine.
aThirdCell = 4 + myCell;   // Works fine.
aThirdCell = 5.6 + myCell; // Works fine.

aThirdCell = 4.5 + 5.5;

aThirdCell = 10;

Overloading Arithmetic Operators

Now that you understand how to write operator+, the rest of the basic arithmetic operators are straightforward. Here are the declarations of +, -, *, and /, where you have to replace <op> with +, -, *, and /, resulting in four functions. You can also overload %, but it doesn’t make sense for the double values stored in SpreadsheetCells.

class SpreadsheetCell
{
    // Omitted for brevity
};

SpreadsheetCell operator<op>(const SpreadsheetCell& lhs,
    const SpreadsheetCell& rhs);

The implementations of operator- and operator* are very similar to the implementation of operator+, so these are not shown. For operator/, the only tricky aspect is remembering to check for division by zero. This implementation throws an exception if division by zero is detected:

SpreadsheetCell operator/(const SpreadsheetCell& lhs,
    const SpreadsheetCell& rhs)
{
    if (rhs.getValue() == 0) {
        throw invalid_argument("Divide by zero.");
    }
    return SpreadsheetCell(lhs.getValue() / rhs.getValue());
}

C++ does not require you to actually implement multiplication in operator*, division in operator/, and so on. You could implement multiplication in operator/, division in operator+, and so forth. However, that would be extremely confusing, and there is no good reason to do so except as a practical joke. Whenever possible, stick to the commonly used operator meanings in your implementations.

class SpreadsheetCell
{
    public:
        // Omitted for brevity
        SpreadsheetCell& operator+=(const SpreadsheetCell& rhs);
        SpreadsheetCell& operator-=(const SpreadsheetCell& rhs);
        SpreadsheetCell& operator*=(const SpreadsheetCell& rhs);
        SpreadsheetCell& operator/=(const SpreadsheetCell& rhs);
        // Omitted for brevity
};

SpreadsheetCell& SpreadsheetCell::operator+=(const SpreadsheetCell& rhs)
{
    set(getValue() + rhs.getValue());
    return *this;
}

SpreadsheetCell myCell(4), aThirdCell(2);
aThirdCell -= myCell;
aThirdCell += 5.4;

5.4 += aThirdCell;

SpreadsheetCell operator+(const SpreadsheetCell& lhs, const SpreadsheetCell& rhs)
{
    auto result(lhs);  // Local copy
    result += rhs;     // Forward to op=() version
    return result;
}

Overloading Comparison Operators

The comparison operators, such as >, <, and ==, are another useful set of operators to define for your classes. Like the basic arithmetic operators, they should be global functions so that you can use implicit conversion on both the left-hand side and the right-hand side of the operator. The comparison operators all return a bool. Of course, you can change the return type, but that’s not recommended.

Here are the declarations, where you have to replace <op> with ==, <, >, !=, <=, and >=, resulting in six functions:

class SpreadsheetCell
{
    // Omitted for brevity
};

bool operator<op>(const SpreadsheetCell& lhs, const SpreadsheetCell& rhs);

Here is the definition of operator==. The others are very similar.

bool operator==(const SpreadsheetCell& lhs, const SpreadsheetCell& rhs)
{
    return (lhs.getValue() == rhs.getValue());
}

In classes with more data members, it might be painful to compare each data member. However, once you’ve implemented == and <, you can write the rest of the comparison operators in terms of those two. For example, here is a definition of operator>= that uses operator<:

bool operator>=(const SpreadsheetCell& lhs, const SpreadsheetCell& rhs)
{
    return !(lhs < rhs);
}

You can use these operators to compare SpreadsheetCells to other SpreadsheetCells, and also to doubles and ints:

if (myCell > aThirdCell || myCell < 10) {
    cout << myCell.getValue() << endl;
}

Building Types with Operator Overloading

Many people find the syntax of operator overloading tricky and confusing, at least at first. The irony is that it’s supposed to make things simpler. As you’ve discovered, that doesn’t mean simpler for the person writing the class, but simpler for the person using the class. The point is to make your new classes as similar as possible to built-in types such as int and double: it’s easier to add objects using + than to remember whether the method name you should call is add() or sum().

At this point, you might be wondering exactly which operators you can overload. The answer is almost all of them—even some you’ve never heard of. You have actually just scratched the surface: you’ve seen the assignment operator in the section on object life cycles, the basic arithmetic operators, the shorthand arithmetic operators, and the comparison operators. Overloading the stream insertion and extraction operators is also useful. In addition, there are some tricky, but interesting, things you can do with operator overloading that you might not anticipate at first. The Standard Library uses operator overloading extensively. Chapter 15 explains how and when to overload the rest of the operators. Chapters 16 to 20 cover the Standard Library.

Using Interface and Implementation Classes

Even with the preceding measures and the best design principles, the C++ language is fundamentally unfriendly to the principle of abstraction. The syntax requires you to combine your public interfaces and private (or protected) data members and methods together in one class definition, thereby exposing some of the internal implementation details of the class to its clients. The downside of this is that if you have to add new non-public methods or data members to your class, all the clients of the class have to be recompiled. This can become a burden in bigger projects.

The good news is that you can make your interfaces a lot cleaner and hide all implementation details, resulting in stable interfaces. The bad news is that it takes a bit of coding. The basic principle is to define two classes for every class you want to write: the interface class and the implementation class. The implementation class is identical to the class you would have written if you were not taking this approach. The interface class presents public methods identical to those of the implementation class, but it only has one data member: a pointer to an implementation class object. This is called the pimpl idiom, private implementation idiom, or bridge pattern. The interface class method implementations simply call the equivalent methods on the implementation class object. The result of this is that no matter how the implementation changes, it has no impact on the public interface class. This reduces the need for recompilation. None of the clients that use the interface class need to be recompiled if the implementation (and only the implementation) changes. Note that this idiom only works if the single data member is a pointer to the implementation class. If it were a by-value data member, the clients would have to be recompiled when the definition of the implementation class changes.

To use this approach with the Spreadsheet class, define a public interface class, Spreadsheet, that looks like this:

#include "SpreadsheetCell.h"
#include <memory>

// Forward declarations
class SpreadsheetApplication;

class Spreadsheet
{
    public:
        Spreadsheet(const SpreadsheetApplication& theApp,
            size_t width = kMaxWidth, size_t height = kMaxHeight);
        Spreadsheet(const Spreadsheet& src);
        ~Spreadsheet();

        Spreadsheet& operator=(const Spreadsheet& rhs);

        void setCellAt(size_t x, size_t y, const SpreadsheetCell& cell);
        SpreadsheetCell& getCellAt(size_t x, size_t y);

        size_t getId() const;

        static const size_t kMaxHeight = 100;
        static const size_t kMaxWidth = 100;

        friend void swap(Spreadsheet& first, Spreadsheet& second) noexcept;

    private:
        class Impl;
        std::unique_ptr<Impl> mImpl;
};

The implementation class, Impl, is a private nested class, because no one else besides the Spreadsheet class needs to know about the implementation class. The Spreadsheet class now contains only one data member: a pointer to an Impl instance. The public methods are identical to the old Spreadsheet.

The nested Spreadsheet::Impl class has almost the same interface as the original Spreadsheet class. However, because the Impl class is a private nested class of Spreadsheet, you cannot have the following global friend swap() function that swaps two Spreadsheet::Impl objects:

friend void swap(Spreadsheet::Impl& first, Spreadsheet::Impl& second) noexcept;

Instead, a private swap() method is defined for the Spreadsheet::Impl class as follows:

void swap(Impl& other) noexcept;

The implementation is straightforward, but you need to remember that this is a nested class, so you need to specify Spreadsheet::Impl::swap() instead of just Impl::swap(). The same holds true for the other members. For details, see the section on nested classes earlier in this chapter. Here is the swap() method:

void Spreadsheet::Impl::swap(Impl& other) noexcept
{
    using std::swap;

    swap(mWidth, other.mWidth);
    swap(mHeight, other.mHeight);
    swap(mCells, other.mCells);
}

Now that the Spreadsheet class has a unique_ptr to the implementation class, the Spreadsheet class needs to have a user-declared destructor. Since we don’t need to do anything in this destructor, it can be defaulted in the implementation file as follows:

Spreadsheet::~Spreadsheet() = default;

This shows that you can default a special member function not only in the class definition, but also in the implementation file.

The implementations of the Spreadsheet methods, such as setCellAt() and getCellAt(), just pass the request on to the underlying Impl object:

void Spreadsheet::setCellAt(size_t x, size_t y, const SpreadsheetCell& cell)
{
    mImpl->setCellAt(x, y, cell);
}

SpreadsheetCell& Spreadsheet::getCellAt(size_t x, size_t y)
{
    return mImpl->getCellAt(x, y);
}

The constructors for the Spreadsheet must construct a new Impl to do its work:

Spreadsheet::Spreadsheet(const SpreadsheetApplication& theApp,
    size_t width, size_t height) 
{
    mImpl = std::make_unique<Impl>(theApp, width, height);
}

Spreadsheet::Spreadsheet(const Spreadsheet& src)
{
    mImpl = std::make_unique<Impl>(*src.mImpl);
}

The copy constructor looks a bit strange because it needs to copy the underlying Impl from the source spreadsheet. The copy constructor takes a reference to an Impl, not a pointer, so you must dereference the mImpl pointer to get to the object itself so the constructor call can take its reference.

The Spreadsheet assignment operator must similarly pass on the assignment to the underlying Impl:

Spreadsheet& Spreadsheet::operator=(const Spreadsheet& rhs)
{
    *mImpl = *rhs.mImpl;
    return *this;
}

The first line in the assignment operator looks a little odd. The Spreadsheet assignment operator needs to forward the call to the Impl assignment operator, which only runs when you copy direct objects. By dereferencing the mImpl pointers, you force direct object assignment, which causes the assignment operator of Impl to be called.

The swap() function simply swaps the single data member:

void swap(Spreadsheet& first, Spreadsheet& second) noexcept
{
    using std::swap;

    swap(first.mImpl, second.mImpl);
} 

This technique to truly separate interface from implementation is powerful. Although it is a bit clumsy at first, once you get used to it, you will find it natural to work with. However, it’s not common practice in most workplace environments, so you might find some resistance to trying it from your coworkers. The most compelling argument in favor of it is not the aesthetic one of splitting out the interface, but the speedup in build time if the implementation of the class changes. When a class is not using the pimpl idiom, a change to its implementation details might trigger a long build. For example, adding a new data member to a class definition triggers a rebuild of all other source files that include this class definition. With the pimpl idiom, you can modify the implementation class definition as much as you like, as long as the public interface class remains untouched, it won’t trigger a long build.

An alternative to separating the implementation from the interface is to use an abstract interface—that is, an interface with only pure virtual methods—and then have an implementation class that implements that interface. See Chapter 10 for a discussion on abstract interfaces.