Reference Variables

Reference variables must be initialized as soon as they are created, like this:

int x = 3;
int& xRef = x;

Subsequent to this assignment, xRef is another name for x. Any use of xRef uses the current value of x. Any assignment to xRef changes the value of x. For example, the following code sets x to 10 through xRef:

xRef = 10;

You cannot declare a reference variable outside of a class without initializing it:

int& emptyRef; // DOES NOT COMPILE!

You cannot create a reference to an unnamed value, such as an integer literal, unless the reference is to a const value. In the following example, unnamedRef1 does not compile because it is a non-const reference to a constant. That would mean you could change the value of the constant, 5, which doesn’t make sense. unnamedRef2 works because it’s a const reference, so you cannot for example write “unnamedRef2 = 7”.

int& unnamedRef1 = 5;       // DOES NOT COMPILE
const int& unnamedRef2 = 5; // Works as expected

The same holds for temporary objects. You cannot have a non-const reference to a temporary object, but a const reference is fine. For example, suppose you have the following function returning an std::string object:

std::string getString() { return "Hello world!"; }

You can have a const reference to the result of calling getString(), and that const reference keeps the std::string object alive until the reference goes out of scope:

std::string& string1 = getString();       // DOES NOT COMPILE
const std::string& string2 = getString(); // Works as expected

int x = 3, y = 4;
int& xRef = x;
xRef = y; // Changes value of x to 4. Doesn't make xRef refer to y.

xRef = &y; // DOES NOT COMPILE!

int x = 3, z = 5;
int& xRef = x;
int& zRef = z;
zRef = xRef; // Assigns values, not references

int* intP;
int*& ptrRef = intP;
ptrRef = new int;
*ptrRef = 5;

int x = 3;
int& xRef = x;
int* xPtr = &xRef; // Address of a reference is pointer to value
*xPtr = 100;

Reference Data Members

As Chapter 9 explains, data members of classes can be references. A reference cannot exist without referring to some other variable. Thus, you must initialize reference data members in the constructor initializer, not in the body of the constructor. The following is a quick example:

class MyClass
{
    public:
        MyClass(int& ref) : mRef(ref) {}
    private:
        int& mRef;
};

Consult Chapter 9 for details.

Reference Parameters

C++ programmers do not often use stand-alone reference variables or reference data members. The most common use of references is for parameters to functions and methods. Recall that the default parameter-passing semantics are pass-by-value: functions receive copies of their arguments. When those parameters are modified, the original arguments remain unchanged. References allow you to specify pass-by-reference semantics for arguments passed to the function. When you use reference parameters, the function receives references to the function arguments. If those references are modified, the changes are reflected in the original argument variables. For example, here is a simple swap function to swap the values of two ints:

void swap(int& first, int& second)
{
    int temp = first;
    first = second;
    second = temp;
}

You can call it like this:

int x = 5, y = 6;
swap(x, y);

When swap() is called with the arguments x and y, the first parameter is initialized to refer to x, and the second parameter is initialized to refer to y. When swap() modifies first and second, x and y are actually changed.

Just as you can’t initialize normal reference variables with constants, you can’t pass constants as arguments to functions that employ pass-by-non-const-reference:

swap(3, 4); // DOES NOT COMPILE

int x = 5, y = 6;
int *xp = &x, *yp = &y;
swap(*xp, *yp);

Reference Return Values

You can also return a reference from a function or method. The main reason to do so is efficiency. Instead of returning a whole object, return a reference to the object to avoid copying it unnecessarily. Of course, you can only use this technique if the object in question continues to exist following the function termination.

Note that if the type you want to return from your function supports move semantics, discussed in Chapter 9, then returning it by value is almost as efficient as returning a reference.

A second reason to return a reference is if you want to be able to assign to the return value directly as an lvalue (the left-hand side of an assignment statement). Several overloaded operators commonly return references. Chapter 9 shows some examples, and you can read about more applications of this technique in Chapter 15.

Rvalue References

An rvalue is anything that is not an lvalue, such as a constant value, or a temporary object or value. Typically, an rvalue is on the right-hand side of an assignment operator. Rvalue references are discussed in detail in Chapter 9, but here is a quick reminder:

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

With only this version of handleMessage(), you cannot call it as follows:

handleMessage("Hello World"); // A literal is not an lvalue.

std::string a = "Hello ";
std::string b = "World";
handleMessage(a + b);         // A temporary is not an lvalue.

To allow these kinds of calls, you need a version that accepts an rvalue reference:

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

See Chapter 9 for more details.

Deciding between References and Pointers

References in C++ could be considered redundant: everything you can do with references, you can accomplish with pointers. For example, you could write the earlier shown swap() function like this:

void swap(int* first, int* second)
{
    int temp = *first;
    *first = *second;
    *second = temp;
}

However, this code is more cluttered than the version with references. References make your programs cleaner and easier to understand. They are also safer than pointers: it’s impossible to have a null reference, and you don’t explicitly dereference references, so you can’t encounter any of the dereferencing errors associated with pointers. These arguments, saying that references are safer, are only valid in the absence of any pointers. For example, take the following function that accepts a reference to an int:

void refcall(int& t) { ++t; }

You could declare a pointer and initialize it to point to some random place in memory. Then you could dereference this pointer and pass it as the reference argument to refcall(), as in the following code. This code compiles fine, but it is undefined what will happen when executed. It could for example cause a crash.

int* ptr = (int*)8;
refcall(*ptr);

Most of the time, you can use references instead of pointers. References to objects even support polymorphism in the same way as pointers to objects. However, there are some use-cases in which you need to use a pointer. One example is when you need to change the location to which it points. Recall that you cannot change the variable to which references refer. For example, when you dynamically allocate memory, you need to store a pointer to the result in a pointer rather than a reference. A second use-case in which you need to use a pointer is when the pointer is optional, that is, when it can be nullptr. Yet another use-case is if you want to store polymorphic types in a container.

A way to distinguish between appropriate use of pointers and references in parameters and return types is to consider who owns the memory. If the code receiving the variable becomes the owner and thus becomes responsible for releasing the memory associated with an object, it must receive a pointer to the object. Better yet, it should receive a smart pointer, which is the recommended way to transfer ownership. If the code receiving the variable should not free the memory, it should receive a reference.

Consider a function that splits an array of ints into two arrays: one of even numbers and one of odd numbers. The function doesn’t know how many numbers in the source array will be even or odd, so it should dynamically allocate the memory for the destination arrays after examining the source array. It should also return the sizes of the two new arrays. Altogether, there are four items to return: pointers to the two new arrays and the sizes of the two new arrays. Obviously, you must use pass-by-reference. The canonical C way to write the function looks like this:

void separateOddsAndEvens(const int arr[], size_t size, int** odds,
    size_t* numOdds, int** evens, size_t* numEvens)
{
    // Count the number of odds and evens
    *numOdds = *numEvens = 0;
    for (size_t i = 0; i < size; ++i) {
        if (arr[i] % 2 == 1) {
            ++(*numOdds);
        } else {
            ++(*numEvens);
        }
    }

    // Allocate two new arrays of the appropriate size.
    *odds = new int[*numOdds];
    *evens = new int[*numEvens];

    // Copy the odds and evens to the new arrays
    size_t oddsPos = 0, evensPos = 0;
    for (size_t i = 0; i < size; ++i) {
        if (arr[i] % 2 == 1) {
            (*odds)[oddsPos++] = arr[i];
        } else {
            (*evens)[evensPos++] = arr[i];
        }
    }
}

The final four parameters to the function are the “reference” parameters. In order to change the values to which they refer, separateOddsAndEvens() must dereference them, leading to some ugly syntax in the function body. Additionally, when you want to call separateOddsAndEvens(), you must pass the address of two pointers so that the function can change the actual pointers, and the address of two ints so that the function can change the actual ints. Note also that the caller is responsible for deleting the two arrays created by separateOddsAndEvens()!

int unSplit[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
int* oddNums = nullptr;
int* evenNums = nullptr;
size_t numOdds = 0, numEvens = 0;

separateOddsAndEvens(unSplit, std::size(unSplit),
    &oddNums, &numOdds, &evenNums, &numEvens);

// Use the arrays...

delete[] oddNums; oddNums = nullptr;
delete[] evenNums; evenNums = nullptr;

If this syntax annoys you (which it should), you can write the same function by using references to obtain true pass-by-reference semantics:

void separateOddsAndEvens(const int arr[], size_t size, int*& odds,
    size_t& numOdds, int*& evens, size_t& numEvens)
{
    numOdds = numEvens = 0;
    for (size_t i = 0; i < size; ++i) {
        if (arr[i] % 2 == 1) {
            ++numOdds;
        } else {
            ++numEvens;
        }
    }

    odds = new int[numOdds];
    evens = new int[numEvens];

    size_t oddsPos = 0, evensPos = 0;
    for (size_t i = 0; i < size; ++i) {
        if (arr[i] % 2 == 1) {
            odds[oddsPos++] = arr[i];
        } else {
            evens[evensPos++] = arr[i];
        }
    }
}

In this case, the odds and evens parameters are references to int*s. separateOddsAndEvens() can modify the int*s that are used as arguments to the function (through the reference), without any explicit dereferencing. The same logic applies to numOdds and numEvens, which are references to ints. With this version of the function, you no longer need to pass the addresses of the pointers or ints. The reference parameters handle it for you automatically:

separateOddsAndEvens(unSplit, std::size(unSplit),
    oddNums, numOdds, evenNums, numEvens);

Even though using reference parameters is already much cleaner than using pointers, it is recommended that you avoid dynamically allocated arrays as much as possible. For example, by using the Standard Library vector container, the previous separateOddsAndEvens() function can be rewritten to be much safer, more elegant, and much more readable, because all memory allocation and deallocation happens automatically:

void separateOddsAndEvens(const vector<int>& arr,
    vector<int>& odds, vector<int>& evens)
{
    for (int i : arr) {
        if (i % 2 == 1) {
            odds.push_back(i);
        } else {
            evens.push_back(i);
        }
    }
}

This version can be used as follows:

vector<int> vecUnSplit = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
vector<int> odds, evens;
separateOddsAndEvens(vecUnSplit, odds, evens);

Note that you don’t need to deallocate the odds and evens containers; the vector class takes care of this. This version is much easier to use than the versions using pointers or references. The Standard Library vector container is discussed in detail in Chapter 17.

The version using vectors is already much better than the versions using pointers or references, but it’s usually recommended to avoid output parameters as much as possible. If a function needs to return something, you should just return it, instead of using output parameters. Especially since C++11 introduced move semantics, returning something by value from a function is efficient. And now that C++17 has introduced structured bindings, see Chapter 1, it is really convenient to return multiple values from a function.

So, for the separateOddsAndEvens() function, instead of accepting two output vectors, it should simply return a pair of vectors. The std::pair utility class, defined in <utility>, is discussed in detail in Chapter 17, but its use is rather straightforward. Basically, a pair can store two values of two different or equal types. It’s a class template, and it requires two types between the angle brackets to specify the type of both values. A pair can be created using std::make_pair(). Here is the separateOddsAndEvens() function returning a pair of vectors:

pair<vector<int>, vector<int>> separateOddsAndEvens(const vector<int>& arr)
{
    vector<int> odds, evens;
    for (int i : arr) {
        if (i % 2 == 1) {
            odds.push_back(i);
        } else {
            evens.push_back(i);
        }
    }
    return make_pair(odds, evens);
}

By using a structured binding, the code to call separateOddsAndEvens() becomes very compact, yet very easy to read and understand:

vector<int> vecUnSplit = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
auto[odds, evens] = separateOddsAndEvens(vecUnSplit);

The const Keyword

The keyword const is short for “constant” and specifies that something remains unchanged. The compiler enforces this requirement by marking any attempt to change it as an error. Furthermore, when optimizations are enabled, the compiler can take advantage of this knowledge to produce better code. The keyword has two related roles. It can mark variables or parameters, and it can mark methods. This section provides a definitive discussion of these two meanings.

const double PI = 3.141592653589793238462;

void func(const int param)
{
     // Not allowed to change param...
}

int* ip;
ip = new int[10];
ip[4] = 5;

const int* ip;
ip = new int[10];
ip[4] = 5; // DOES NOT COMPILE!

int const* ip;
ip = new int[10];
ip[4] = 5; // DOES NOT COMPILE!

int* const ip = nullptr;
ip = new int[10]; // DOES NOT COMPILE!
ip[4] = 5;        // Error: dereferencing a null pointer

int* const ip = new int[10];
ip[4] = 5;

int const* const ip = nullptr;

const int* const ip = nullptr;

int const* const ip = nullptr;

const int* const ip = nullptr;

const int * const * const * const ip = nullptr;

int z;
const int& zRef = z;
zRef = 4; // DOES NOT COMPILE

void doSomething(const BigClass& arg)
{
   // Implementation here
}

const int getArraySize() { return 32; }

int main()
{
    int myArray[getArraySize()];    // Invalid in C++
    return 0;
}

constexpr int getArraySize() { return 32; }

int main()
{
    int myArray[getArraySize()];    // OK
    return 0;
}

int myArray[getArraySize() + 1];    // OK

class Rect
{
    public:
        constexpr Rect(size_t width, size_t height)
            : mWidth(width), mHeight(height) {}

        constexpr size_t getArea() const { return mWidth * mHeight; }
    private:
        size_t mWidth, mHeight;
};

constexpr Rect r(8, 2);
int myArray[r.getArea()];    // OK

The static Keyword

There are several uses of the keyword static in C++, all seemingly unrelated. Part of the motivation for “overloading” the keyword was attempting to avoid having to introduce new keywords into the language.

void f();

int main()
{
    f();
    return 0;
}

#include <iostream>

void f();

void f()
{
    std::cout << "f
";
}

#include <iostream>

static void f();

void f()
{
    std::cout << "f
";
}

#include <iostream>

namespace {
    void f();

    void f()
    {
        std::cout << "f
";
    }
}

extern int x;
int x = 3;

extern int x = 3;

#include <iostream>

extern int x;

int main()
{
    std::cout << x << std::endl;
}

void performTask()
{
    static bool initialized = false;
    if (!initialized) {
        cout << "initializing" << endl;
        // Perform initialization.
        initialized = true;
    }
    // Perform the desired task.
}

Order of Initialization of Nonlocal Variables

Before leaving the topic of static data members and global variables, consider the order of initialization of these variables. All global variables and static class data members in a program are initialized before main() begins. The variables in a given source file are initialized in the order they appear in the source file. For example, in the following file, Demo::x is guaranteed to be initialized before y:

class Demo
{
    public:
        static int x;
};
int Demo::x = 3;
int y = 4;

However, C++ provides no specifications or guarantees about the initialization ordering of nonlocal variables in different source files. If you have a global variable x in one source file and a global variable y in another, you have no way of knowing which will be initialized first. Normally, this lack of specification isn’t cause for concern. However, it can be problematic if one global or static variable depends on another. Recall that initialization of objects implies running their constructors. The constructor of one global object might access another global object, assuming that it is already constructed. If these two global objects are declared in two different source files, you cannot count on one being constructed before the other, and you cannot control the order of initialization. This order might not be the same for different compilers or even different versions of the same compiler, and the order might even change when you simply add another file to your project.

Order of Destruction of Nonlocal Variables

Nonlocal variables are destroyed in the reverse order they were initialized. Nonlocal variables in different source files are initialized in an undefined order, which means that the order of destruction is also undefined.

Type Aliases

A type alias provides a new name for an existing type declaration. You can think of a type alias as syntax for introducing a synonym for an existing type declaration without creating a new type. The following gives a new name, IntPtr, to the int* type declaration:

using IntPtr = int*;

You can use the new type name and the definition it aliases interchangeably. For example, the following two lines are valid:

int* p1;
IntPtr p2;

Variables created with the new type name are completely compatible with those created with the original type declaration. So, it is perfectly valid, given these definitions, to write the following, because they are not just “compatible” types, they are the same type:

p1 = p2;
p2 = p1;

The most common use for type aliases is to provide manageable names when the real type declarations become too unwieldy. This situation commonly arises with templates. For example, Chapter 1 introduces the std::vector from the Standard Library. To declare a vector of strings, you need to declare it as std::vector<std::string>. It’s a templated class, and thus requires you to specify the template parameters any time you want to refer to the type of this vector. Templates are discussed in detail in Chapter 12. For declaring variables, specifying function parameters, and so on, you would have to write std::vector<std::string>:

void processVector(const std::vector<std::string>& vec) { /* omitted */ }

int main()
{
    std::vector<std::string> myVector;
    processVector(myVector);
    return 0;
}

With a type alias, you can create a shorter, more meaningful name:

using StringVector = std::vector<std::string>;

void processVector(const StringVector& vec) { /* omitted */ }

int main()
{
    StringVector myVector;
    processVector(myVector);
    return 0;
}

Type aliases can include the scope qualifiers. The preceding example shows this by including the scope std for StringVector.

The Standard Library uses type aliases extensively to provide shorter names for types. For example, std::string is actually a type alias that looks like this:

using string = basic_string<char>;

Type Aliases for Function Pointers

You don’t normally think about the location of functions in memory, but each function actually lives at a particular address. In C++, you can use functions as data. In other words, you can take the address of a function and use it like you use a variable.

Function pointers are typed according to the parameter types and return type of compatible functions. One way to work with function pointers is to use a type alias. A type alias allows you to assign a type name to the family of functions that have the given characteristics. For example, the following line defines a type called MatchFunction that represents a pointer to any function that has two int parameters and returns a bool:

using MatchFunction = bool(*)(int, int);

Now that this new type exists, you can write a function that takes a MatchFunction as a parameter. For example, the following function accepts two int arrays and their size, as well as a MatchFunction. It iterates through the arrays in parallel and calls the MatchFunction on corresponding elements of both arrays, printing a message if the call returns true. Notice that even though the MatchFunction is passed in as a variable, it can be called just like a regular function:

void findMatches(int values1[], int values2[], size_t numValues,
                 MatchFunction matcher)
{
    for (size_t i = 0; i < numValues; i++) {
        if (matcher(values1[i], values2[i])) {
            cout << "Match found at position " << i <<
                " (" << values1[i] << ", " << values2[i] << ")" << endl;
        }
    }
}

Note that this implementation requires that both arrays have at least numValues elements. To call the findMatches() function, all you need is any function that adheres to the defined MatchFunction type—that is, any type that takes in two ints and returns a bool. For example, consider the following function, which returns true if the two parameters are equal:

bool intEqual(int item1, int item2)
{
    return item1 == item2;
}

Because the intEqual() function matches the MatchFunction type, it can be passed as the final argument to findMatches(), as follows:

int arr1[] = { 2, 5, 6, 9, 10, 1, 1 };
int arr2[] = { 4, 4, 2, 9, 0, 3, 4 };
size_t arrSize = std::size(arr1); // Pre-C++17: sizeof(arr1)/sizeof(arr1[0]);
cout << "Calling findMatches() using intEqual():" << endl;
findMatches(arr1, arr2, arrSize, &intEqual);

The intEqual() function is passed into the findMatches() function by taking its address. Technically, the & character is optional—if you omit it and only put the function name, the compiler will know that you mean to take its address. The output is as follows:

Calling findMatches() using intEqual():
Match found at position 3 (9, 9)

The benefit of function pointers lies in the fact that findMatches() is a generic function that compares parallel values in two arrays. As it is used here, it compares based on equality. However, because it takes a function pointer, it could compare based on other criteria. For example, the following function also adheres to the definition of MatchFunction:

bool bothOdd(int item1, int item2)
{
    return item1 % 2 == 1 && item2 % 2 == 1;
}

The following code calls findMatches() using bothOdd:

cout << "Calling findMatches() using bothOdd():" << endl;
findMatches(arr1, arr2, arrSize, &bothOdd);

The output is as follows:

Calling findMatches() using bothOdd():
Match found at position 3 (9, 9)
Match found at position 5 (1, 3)

By using function pointers, a single function, findMatches(), is customized to different uses based on a parameter, matcher.

While function pointers in C++ are uncommon, you may need to obtain function pointers in certain cases. Perhaps the most common example of this is when obtaining a pointer to a function in a dynamic link library. The following example obtains a pointer to a function in a Microsoft Windows Dynamic Link Library (DLL). Details of Windows DLLs are outside the scope of this book on platform-independent C++, but it is so important to Windows programmers that it is worth discussing, and it is a good example to explain the details of function pointers in general.

Consider a DLL, hardware.dll, that has a function called Connect(). You would like to load this library only if you need to call Connect(). Loading the library at run-time is done with the Windows LoadLibrary() kernel function:

HMODULE lib = ::LoadLibrary("hardware.dll");

The result of this call is what is called a “library handle” and will be NULL if there is an error. Before you can load the function from the library, you need to know the prototype for the function. Suppose the following is the prototype for Connect(), which returns an integer and accepts three parameters: a Boolean, an integer, and a C-style string.

int __stdcall Connect(bool b, int n, const char* p);

The __stdcall is a Microsoft-specific directive to specify how parameters are passed to the function and how they are cleaned up.

You can now use a type alias to define a name (ConnectFunction) for a pointer to a function with the preceding prototype:

using ConnectFunction = int(__stdcall*)(bool, int, const char*);

Having successfully loaded the library and defined a name for the function pointer, you can get a pointer to the function in the library as follows:

ConnectFunction connect = (ConnectFunction)::GetProcAddress(lib, "Connect");

If this fails, connect will be nullptr. If it succeeds, you can call the loaded function:

connect(true, 3, "Hello world");

A C programmer might think that you need to dereference the function pointer before calling it as follows:

(*connect)(true, 3, "Hello world");

This was true decades ago, but now, every C and C++ compiler is smart enough to know how to automatically dereference a function pointer before calling it.

Type Aliases for Pointers to Methods and Data Members

You can create and use pointers to both variables and functions. Now, consider pointers to class data members and methods. It’s perfectly legitimate in C++ to take the addresses of class data members and methods in order to obtain pointers to them. However, you can’t access a non-static data member or call a non-static method without an object. The whole point of class data members and methods is that they exist on a per-object basis. Thus, when you want to call the method or access the data member via the pointer, you must dereference the pointer in the context of an object. Here is an example using the Employee class introduced in Chapter 1:

Employee employee;
int (Employee::*methodPtr) () const = &Employee::getSalary;
cout << (employee.*methodPtr)() << endl;

Don’t panic at the syntax. The second line declares a variable called methodPtr of type pointer to a non-static const method of Employee that takes no arguments and returns an int. At the same time, it initializes this variable to point to the getSalary() method of the Employee class. This syntax is quite similar to declaring a simple function pointer, except for the addition of Employee:: before the *methodPtr. Note also that the & is required in this case.

The third line calls the getSalary() method (via the methodPtr pointer) on the employee object. Note the use of parentheses surrounding employee.*methodPtr. They are needed because () has higher precedence than *.

The second line can be made easier to read with a type alias:

Employee employee;
using PtrToGet = int (Employee::*) () const;
PtrToGet methodPtr = &Employee::getSalary;
cout << (employee.*methodPtr)() << endl;

Using auto, it can be simplified even further:

Employee employee;
auto methodPtr = &Employee::getSalary;
cout << (employee.*methodPtr)() << endl;

Pointers to methods and data members usually won’t come up in your programs. However, it’s important to keep in mind that you can’t dereference a pointer to a non-static method or data member without an object. Every so often, you may want to try something like passing a pointer to a non-static method to a function such as qsort() that requires a function pointer, which simply won’t work.

typedefs

Type aliases were introduced in C++11. Before C++11, you had to use typedefs to accomplish something similar but in a more convoluted way.

Just as a type alias, a typedef provides a new name for an existing type declaration. For example, take the following type alias:

using IntPtr = int*;

Without type aliases, you had to use a typedef which looked as follows:

typedef int* IntPtr;

As you can see, it’s much less readable! The order is reversed, which causes a lot of confusion, even for professional C++ developers. Other than being more convoluted, a typedef behaves almost the same as a type alias. For example, the typedef can be used as follows:

IntPtr p;

Before type aliases were introduced, you also had to use typedefs for function pointers, which is even more convoluted. For example, take the following type alias:

using FunctionType = int (*)(char, double);

Defining the same FunctionType with a typedef looks as follows:

typedef int (*FunctionType)(char, double);

This is more convoluted because the name FunctionType is somewhere in the middle of it.

Type aliases and typedefs are not entirely equivalent. Compared to typedefs, type aliases are more powerful when used with templates, but that is covered in Chapter 12 because it requires more details about templates.

Casts

C++ provides four specific casts: const_cast(), static_cast(), reinterpret_cast(), and dynamic_cast().

The old C-style casts with () still work in C++, and are still used extensively in existing code bases. C-style casts cover all four C++ casts, so they are more error-prone because it’s not always obvious what you are trying to achieve, and you might end up with unexpected results. I strongly recommend you only use the C++ style casts in new code because they are safer and stand out better syntactically in your code.

This section describes the purposes of each C++ cast and specifies when you would use each of them.

extern void ThirdPartyLibraryMethod(char* str);

void f(const char* str)
{
    ThirdPartyLibraryMethod(const_cast<char*>(str));
}

std::string str = "C++";
const std::string& constStr = std::as_const(str);

auto result = std::as_const(str);

int i = 3;
int j = 4;
double result = static_cast<double>(i) / j;

class Base
{
    public:
        virtual ~Base() = default;
};

class Derived : public Base
{
    public:
        virtual ~Derived() = default;
};

int main()
{
    Base* b;
    Derived* d = new Derived();
    b = d; // Don't need a cast to go up the inheritance hierarchy
    d = static_cast<Derived*>(b); // Need a cast to go down the hierarchy

    Base base;
    Derived derived;
    Base& br = derived;
    Derived& dr = static_cast<Derived&>(br);
    return 0;
}

Base* b = new Base();
Derived* d = static_cast<Derived*>(b);

class X {};
class Y {};

int main()
{
    X x;
    Y y;
    X* xp = &x;
    Y* yp = &y;
    // Need reinterpret cast for pointer conversion from unrelated classes
    // static_cast doesn't work.
    xp = reinterpret_cast<X*>(yp);
    // No cast required for conversion from pointer to void*
    void* p = xp;
    // Need reinterpret cast for pointer conversion from void*
    xp = reinterpret_cast<X*>(p);
    // Need reinterpret cast for reference conversion from unrelated classes
    // static_cast doesn't work.
    X& xr = x;
    Y& yr = reinterpret_cast<Y&>(x);
    return 0;
}

class Base
{
    public:
        virtual ~Base() = default;
};

class Derived : public Base
{
    public:
        virtual ~Derived() = default;
};

Base* b;
Derived* d = new Derived();
b = d;
d = dynamic_cast<Derived*>(b);

Base base;
Derived derived;
Base& br = base;
try {
    Derived& dr = dynamic_cast<Derived&>(br);
} catch (const bad_cast&) {
    cout << "Bad cast!" << endl;
}

error C2683: 'dynamic_cast' : 'MyClass' is not a polymorphic type.

[[noreturn]]

[[noreturn]]means that a function never returns control to the call site. Typically, the function either causes some kind of termination (process termination or thread termination), or throws an exception. With this attribute, the compiler can avoid giving certain warnings or errors because it now knows more about the intent of the function. Here is an example:

[[noreturn]] void forceProgramTermination()
{
    std::exit(1);
}

bool isDongleAvailable()
{
    bool isAvailable = false;
    // Check whether a licensing dongle is available...
    return isAvailable;
}

bool isFeatureLicensed(int featureId)
{
    if (!isDongleAvailable()) {
    // No licensing dongle found, abort program execution!
        forceProgramTermination();
    } else {
        bool isLicensed = false;
        // Dongle available, perform license check of the given feature...
        return isLicensed;
    }
}

int main()
{
    bool isLicensed = isFeatureLicensed(42);
}

This code snippet compiles fine without any warnings or errors. However, if you remove the [[noreturn]] attribute, the compiler generates the following warning (output from Visual C++):

warning C4715: 'isFeatureLicensed': not all control paths return a value

[[deprecated]]

[[deprecated]] can be used to mark something as deprecated, which means you can still use it, but its use is discouraged. This attribute accepts an optional argument that can be used to explain the reason of the deprecation, as in this example:

[[deprecated("Unsafe method, please use xyz")]] void func();

If you use this deprecated function, you’ll get a compilation error or warning. For example, GCC gives the following warning:

warning: 'void func()' is deprecated: Unsafe method, please use xyz

[[fallthrough]]

Starting with C++17, you can tell the compiler that a fallthrough in a switch statement is intentional using the [[fallthrough]] attribute. If you don’t specify this attribute for intentional fallthroughs, the compiler might give you a warning. You don’t need to specify the attribute for empty cases. For example:

switch (backgroundColor) {
    case Color::DarkBlue:
        doSomethingForDarkBlue();
        [[fallthrough]];
    case Color::Black:
        // Code is executed for both a dark blue or black background color
        doSomethingForBlackOrDarkBlue();
        break;
    case Color::Red:
    case Color::Green:
        // Code to execute for a red or green background color
        break;
}

[[nodiscard]]

The [[nodiscard]] attribute can be used on a function returning a value to let the compiler issue a warning when that function is used without doing something with the returned value. Here is an example:

[[nodiscard]] int func()
{
    return 42;
}

int main()
{
    func();
    return 0;
}

The compiler issues a warning similar to the following:

warning C4834: discarding return value of function with 'nodiscard' attribute

This feature can, for example, be used for functions that return error codes. By adding the [[nodiscard]] attribute to such functions, the error codes cannot be ignored.

[[maybe_unused]]

The [[maybe_unused]] attribute can be used to suppress the compiler from issuing a warning when something is unused, as in this example:

int func(int param1, int param2)
{
    return 42;
}

If your compiler warning level is set high enough, this function definition might result in two compiler warnings. For example, Microsoft VC++ gives these warnings:

warning C4100: 'param2': unreferenced formal parameter
warning C4100: 'param1': unreferenced formal parameter

By using the [[maybe_unused]] attribute, you can suppress such warnings:

int func(int param1, [[maybe_unused]] int param2)
{
    return 42;
}

In this case, the second parameter is marked with the attribute suppressing its warning. The compiler now only issues a warning for param1:

warning C4100: 'param1': unreferenced formal parameter

Vendor-Specific Attributes

Most attributes will be vendor-specific extensions. Vendors are advised not to use attributes to change the meaning of the program, but to use them to help the compiler to optimize code or detect errors in code. Because attributes of different vendors could clash, vendors are recommended to qualify them. Here is an example:

[[clang::noduplicate]]

Standard User-Defined Literals

C++ defines the following standard user-defined literals. Note that these standard user-defined literals do not start with an underscore.

• “s” for creating std::strings
  For example: auto myString = "Hello World"s;
  Requires a using namespace std::string_literals;
• “sv” for creating std::string_views
  For example: auto myStringView = "Hello World"sv;
  Requires a using namespace std::string_view_literals;
• “h”, “min”, “s”, “ms”, “us”, “ns”, for creating std::chrono::duration time intervals, discussed in Chapter 20
  For example: auto myDuration = 42min;
  Requires a using namespace std::chrono_literals;
• “i”, “il”, “if” for creating complex numbers, complex<double>, complex<long double>, and complex<float>, respectively
  For example: auto myComplexNumber = 1.3i;
  Requires a using namespace std::complex_literals;

A using namespace std; also makes these standard user-defined literals available.

Variable-Length Argument Lists

This section explains the old C-style variable-length argument lists. You need to know how these work because you might find them in legacy code. However, in new code you should use variadic templates for type-safe variable-length argument lists, which are described in Chapter 22.

Consider the C function printf() from <cstdio>. You can call it with any number of arguments:

printf("int %d
", 5);
printf("String %s and int %d
", "hello", 5);
printf("Many ints: %d, %d, %d, %d, %d
", 1, 2, 3, 4, 5);

C/C++ provides the syntax and some utility macros for writing your own functions with a variable number of arguments. These functions usually look a lot like printf(). Although you shouldn’t need this feature very often, occasionally you will run into situations in which it’s quite useful. For example, suppose you want to write a quick-and-dirty debug function that prints strings to stderr if a debug flag is set, but does nothing if the debug flag is not set. Just like printf(), this function should be able to print strings with an arbitrary number of arguments and arbitrary types of arguments. A simple implementation looks like this:

#include <cstdio>
#include <cstdarg>

bool debug = false;

void debugOut(const char* str, ...)
{
    va_list ap;
    if (debug) {
        va_start(ap, str);
        vfprintf(stderr, str, ap);
        va_end(ap);
    }
}

First, note that the prototype for debugOut() contains one typed and named parameter str, followed by ... (ellipses). They stand for any number and type of arguments. In order to access these arguments, you must use macros defined in <cstdarg>. You declare a variable of type va_list, and initialize it with a call to va_start. The second parameter to va_start() must be the rightmost named variable in the parameter list. All functions with variable-length argument lists require at least one named parameter. The debugOut() function simply passes this list to vfprintf() (a standard function in <cstdio>). After the call to vfprintf() returns, debugOut() calls va_end() to terminate the access of the variable argument list. You must always call va_end() after calling va_start() to ensure that the function ends with the stack in a consistent state.

You can use the function in the following way:

debug = true;
debugOut("int %d
", 5);
debugOut("String %s and int %d
", "hello", 5);
debugOut("Many ints: %d, %d, %d, %d, %d
", 1, 2, 3, 4, 5);

void printInts(size_t num, ...)
{
    int temp;
    va_list ap;
    va_start(ap, num);
    for (size_t i = 0; i < num; ++i) {
        temp = va_arg(ap, int);
        cout << temp << " ";
    }
    va_end(ap);
    cout << endl;
}

printInts(5, 5, 4, 3, 2, 1);

Preprocessor Macros

You can use the C++ preprocessor to write macros, which are like little functions. Here is an example:

#define SQUARE(x) ((x) * (x)) // No semicolon after the macro definition!

int main()
{
    cout << SQUARE(5) << endl;
    return 0;
}

Macros are a remnant from C that are quite similar to inline functions, except that they are not type-checked, and the preprocessor dumbly replaces any calls to them with their expansions. The preprocessor does not apply true function-call semantics. This behavior can cause unexpected results. For example, consider what would happen if you called the SQUARE macro with 2 + 3 instead of 5, like this:

cout << SQUARE(2 + 3) << endl;

You expect SQUARE to calculate 25, which it does. However, what if you left off some parentheses on the macro definition, so that it looks like this?

#define SQUARE(x) (x * x)

Now, the call to SQUARE(2 + 3) generates 11, not 25! Remember that the macro is dumbly expanded without regard to function-call semantics. This means that any x in the macro body is replaced by 2 + 3, leading to this expansion:

cout << (2 + 3 * 2 + 3) << endl;

Following proper order of operations, this line performs the multiplication first, followed by the additions, generating 11 instead of 25!

Macros can also have a performance impact. Suppose you call the SQUARE macro as follows:

cout << SQUARE(veryExpensiveFunctionCallToComputeNumber()) << endl;

The preprocessor replaces this with the following:

cout << ((veryExpensiveFunctionCallToComputeNumber()) * 
         (veryExpensiveFunctionCallToComputeNumber())) << endl;

Now you are calling the expensive function twice—another reason to avoid macros.

Macros also cause problems for debugging because the code you write is not the code that the compiler sees, or that shows up in your debugger (because of the search-and-replace behavior of the preprocessor). For these reasons, you should avoid macros entirely in favor of inline functions. The details are shown here only because quite a bit of C++ code out there still employs macros. You need to understand them in order to read and maintain that code.