Constants and const-Correctness

In our original lesson on references, we introduced the concept of pass-by value. This means that, when we call a function, the parameters are generated by creating copies of the arguments. Below, MyFunction() receives a copy of Player.

Character Class|Show
1class Character {/*...*/};
12
13// Passing by value
14void MyFunction(Character Input) {}
15
16int main() {
17  Character Player;
18  MyFunction(Player);
19}

When our parameters are non-trivial, this can be problematic, as copying a complex object has a performance overhead. Additionally, it’s quite unusual for our functions to actually require a copy. Therefore, we prefer to pass objects by reference (or pointer) where possible.

Below, MyFunction() and main() share the same copy of Player. MyFunction() can access Player through the Input reference:

Character Class|Show
1class Character {/*...*/};
12
13// Passing by reference
14void MyFunction(Character& Input) {}
15
16int main() {
17  Character Player;
18  MyFunction(Player);
19}

References

This lesson demystifies references, explaining how they work, their benefits, and their role in performance and data manipulation

const-Correctness

However, passing by reference opens up another problem. When we pass an object to a function by value, we know our object is not going to be modified by that function call. Any action the function performs on the object will be performed on a copy - our original object will be safe.

When we pass by reference, that is no longer the case. The function could modify our object, so we need to consider what state our object could be in after our function call:

Character Class|Show
1class Character {/*...*/};
12
13void MyFunction(Character& Input) {}
14
15int main() {
16  Character Player;
17  MyFunction(Player);
18  // What is Player's health now?
19}

Having to read through a function’s body (or documentation) to understand what effect it can have on our variable is quite annoying. Fortunately, in almost all cases, a function will not change the object at all. It is simply receiving it by reference to avoid the performance impact of creating a copy.

In these scenarios, we can mark the parameter as const. This communicates to the caller that their variable isn’t going to be modified, and asks the compiler to take steps to ensure that it is not modified.

Character Class|Show
1class Character {/*...*/};
12
13void MyFunction(const Character& Input) {}
14
15int main() {
16  Character Player;
17  MyFunction(Player);
18  // What is Player's health now?
19}

When our code correctly marks variables that won’t be changed as const, it is considered ***const-correct***.

1void MyFunction(Character& const Input) {}

const Member Functions

In this lesson, we will explain how they can be used in many other situations. The const keyword can be used in a lot of different ways in C++, and they interact to help us fully implement const-correctness.

In our previous example, we marked our Character as const, meaning the compiler will stop us from doing anything that could change it. This includes calling any functions on the object. The following program will generate a compilation error when we try to call GetHealth() on our const reference:

1#include <iostream>
2
3class Character {
4 public:
5  int GetHealth() { return mHealth; }
6  void SetHealth(int Health) {
7    mHealth = Health;
8  }
9
10 private:
11  int mHealth{100};
12};
13
14void MyFunction(const Character& Input) {
15  std::cout << "Health: " << Input.GetHealth();
16}
17
18int main() {
19  Character Player;
20  MyFunction(Player);
21}

In this class, GetHealth() isn’t modifying the object - it’s simply reading a variable. So, we should mark that function as const too. This asks the compiler to ensure nothing in the GetHealth() function body modifies our object:

1#include <iostream>
2
3class Character {
4 public:
5  int GetHealth() const { return mHealth; }
6  void SetHealth(int Health) {
7    mHealth = Health;
8  }
9
10 private:
11  int mHealth{100};
12};
13
14void MyFunction(const Character& Input) {
15  std::cout << "Health: " << Input.GetHealth();
16}
17
18int main() {
19  Character Player;
20  MyFunction(Player);
21}

A side effect of this is that it also fixes the compilation error we had. Since we declared the GetHealth() function does not modify the object, we can now call it with a const reference. Our previous program now compiles successfully, and outputs:

1Health: 100

const Variables

We’re not restricted to just using const with references. We can declare any variable as const:

1int main() {
2  const int Health{100};
3  Health++;
4}

1error: expression must be modifiable

Member variables can also be const:

1class Character {
2 public:
3  const int Level{1};
4};
5
6int main() {
7  Character Player;
8  Player.Level++;
9}

1error: 'Player': you cannot assign to a variable that is const

Additionally, identifiers that point to complex objects can be const, even if they’re not references:

1class Character {
2 public:
3  int Level{1};
4};
5
6int main() {
7  Character PlayerOne;
8  PlayerOne.Level++; // this is fine
9
10  const Character PlayerTwo;
11  PlayerTwo.Level++; // this is not 
12}

1error: 'PlayerTwo': you cannot assign to a variable that is const

By marking a variable as const, the compiler will also prevent us from creating a reference to that variable, unless the reference is also const:

1class Character {
2 public:
3  int Level{1};
4};
5
6// Passing by non-const reference
7void MyFunction(Character& Input) {}
8
9int main() {
10  Character PlayerOne;
11  MyFunction(PlayerOne); // this is fine
12
13  const Character PlayerTwo;
14  MyFunction(PlayerTwo); // this is not
15}

1error: cannot convert argument 1 from 'const Character' to 'Character &'

Finally, we can copy a const variable to a non-const variable. This is most relevant when passing a const variable by value to a non-const function parameter. This is allowed because, within the function, any modifications would be done to a copy.

As we’ve seen before, the original const variable is not being modified:

1#include <iostream>
2
3void MyFunction(int Number) {
4  // incrementing a copy
5  Number++;
6}
7
8int main() {
9  const int Number{5};
10
11  // Passing a const variable by value to a
12  // non-const function parameter is fine
13  MyFunction(Number);
14
15  std::cout << "Number is still " << Number;
16}

1Number is still 5

const Pointers

An interesting property comes up when considering const from the perspective of pointers. This is because the pointer, and the thing it is pointing at, are two separate objects.

Therefore, our use of const in this context can take four different forms:

Nothing is const

When neither the pointer nor the object being pointed at are const, we can modify either of them. Below, we update our object through the pointer, and then we update the pointer itself. Both are allowed:

1int main() {
2  int Number{5};
3  int* Ptr{&Number};
4
5  // We can modify the object
6  (*Ptr)++;
7
8  // We can modify the pointer
9  Ptr = nullptr;
10}

The pointer is const

When we mark the pointer as const, we cannot update it. However, we can still update the object it is pointing at. We mark the pointer as const by placing the const keyword after the * on the type:

1int main() {
2  int Number{5};
3  int* const Ptr{&Number};
4
5  // We can modify the object
6  (*Ptr)++;
7
8  // We can NOT modify the pointer
9  Ptr = nullptr;
10}

A pointer of this type is colloquially referred to as a "const pointer"

The object being pointed at is const

When the object being pointed at is const, we can’t update it through the pointer, but we can update what the pointer is pointing at. We mark the object as const by placing the const keyword at the start of the type:

1int main() {
2  int Number{5};
3  const int* Ptr{&Number};
4
5  // We can NOT modify the object
6  (*Ptr)++;
7
8  // We can modify the pointer
9  Ptr = nullptr;
10}

A pointer of this type is colloquially referred to as a "pointer to const"

Both the pointer and the object are const

Finally, it is possible for both the pointer and the object being pointed at to be const. We implement this using the const keyword twice - once before the * and once after:

1int main() {
2  int Number{5};
3  const int* const Ptr{&Number};
4
5  // We can NOT modify the object
6  (*Ptr)++;
7
8  // We can NOT modify the pointer
9  Ptr = nullptr;
10}

A pointer of this type is colloquially referred to as a "const pointer to const"

To summarise:

• pointer to int: int* Num
• const pointer to int: int* const Num
• pointer to const int: const int* Num
• const pointer to const int: const int* const Num

This syntax is very likely to be confusing, and nobody is expected to remember it. The important thing to remember is the concept - the pointer and the object being pointed at are two different things, and either of them can be const.

1// Equivalent to const int* Ptr;
2int const* Ptr;

1// Equivalent to const int* const Ptr;
2int const* const Ptr;

const Return Types

Function return types can be marked as const. However, there are some implications here we should be aware of. We can imagine the caller will receive the objects returned by functions by value, so they will receive copies of the object.

Therefore, the value received by the caller will not be const, unless the caller marks them as const:

1const int GetNumber() {
2  return 1;
3}
4
5int main() {
6  int A{GetNumber()};
7  A++; // This is fine
8
9  const int B{GetNumber()};
10  B++; // This is not
11}

And if the caller marks them const, they will be const regardless of what the function prototype declared. The net effect of this is that there is no reason to mark function return types as const.

Additionally, marking return types as const can impair performance, as it interferes with return value optimization - a compiler feature we’ll cover in detail in the next course.

Note this advice only applies to values returned from functions. It is reasonable for functions to return a constant reference if needed:

1class Character {};
2
3Character Player;
4
5const Character& GetPlayer() {
6  return Player;
7}
8
9int main() {
10  const Character& PlayerPointer{GetPlayer()};
11}

Similarly, returning a pointer to const can make sense:

1class Character {};
2
3Character Player;
4
5const Character* GetPlayer() {
6  return &Player;
7}
8
9int main() {
10  const Character* PlayerPointer{GetPlayer()};
11}

Compile Time Constants and constexpr

We can imagine there being two types of constant variables - those that are known when we build our software, and those that can't be known until our software runs.

Almost all of the variables we've seen so far have been known at compile time and could be compile-time constants. An example of a compile-time constant is something like this:

1const float Gravity { 9.8 };

Many other variables cannot be known until the program is run. Examples of these variables might include:

• the time the application was launched
• information about the user's hardware
• anything that is based on user input

The more things that can be done at compile time, the more performant our software will be. Compilers can often detect when our code is creating compile-time constants, and optimize them for us automatically.

However, we can make sure that a variable is a compile-time constant (and have the compiler alert us if it doesn't seem to be) by using the constexpr (short for constant expression) keyword.

1constexpr float Gravity { 9.8 };

When to avoid using const

Even though there are many situations where we can use const, it's not always a good idea.

As we covered above, there's no reason to use const for a value returned by a function:

1const int Add(int x, int y) {
2  return x + y;
3}

Due to the way values are returned from functions, the use of const in that context does not behave as we might expect. It can also degrade performance.

Also, const is less important for arguments that are passed by value. Passing by value means the incoming data is copied. Callers of a function are generally not going to care about what happens to a copy of their data.

As such, it is not particularly important whether we mark these as const. Below, both our parameters could be const, but many would argue it would just be adding noise to our code:

1int Add(int x, int y) {
2  return x + y;
3}

Similarly, it may not be worth marking a simple local variable as const. In the following example, Damage could be const, but the variable is discarded after two lines of code:

1void TakeDamage() {
2  int Damage { isImmune ? 0 : 100 };
3  Health -= Damage;
4}

Different people and companies will have different opinions on these topics.

The Unreal coding standard asks for const to be used anywhere it is applicable:

Google's style guide is less prescriptive, suggesting we "use const whenever it makes sense":

• they encourage const to be used for function parameters that are pass-by-reference
• they encourage const to be used for class methods that do not modify the object
• they are indifferent to the use of const for local variables
• they discourage const for function parameters that are passed by value

Removing const with const_cast

Whilst we should try to make our code const correct, we're inevitably going to find ourselves interacting with other code that isn't.

When this happens, we'd ideally want to update that other code, but that isn't always an option. For example, that code might be in a 3rd party library that we're not able to modify.

This can leave us in a situation where we know a function isn’t going to modify a parameter, but they have neglected to mark it as const:

1// Assume we can't change the code in this
2namespace SomeLibrary {
3  // This function doesn't modify Input,
4  // but has not marked it as const
5  float LogHealth(Character& Input) {
6    std::cout << "Health: "
7      << Input.GetHealth();
8  }
9}

Meanwhile, our const-correct code wants to use this function, but the compiler will prevent us from doing so because we can’t create a non-const reference from a const reference::

1#include <iostream>
2
Character Class|Show
3class Character {/*...*/};
14
SomeLibrary Namespace|Show
15namespace SomeLibrary {/*...*/};
22
23void Report(const Character& Input) {
24  SomeLibrary::LogHealth(Input);
25}
26
27int main() {
28  Character Player;
29  Report(Player);
30}

1error: 'float SomeLibrary::LogHealth(Character &)':
2cannot convert argument 1 from 'const Character' to 'Character &'

For these situations, we have const_cast. This will remove the "constness" of a reference or the value pointed to by a pointer.

1int x { 5 }
2
3const int* Pointer { &x };
4int* NonConstPointer {
5  const_cast<int*>(Pointer)
6};
7
8const int& Reference { x };
9int& NonConstReference {
10  const_cast<int&>(Reference)
11};

We can update our previous program to make use of this:

1#include <iostream>
2
Character Class|Show
3class Character {/*...*/};
14
SomeLibrary Namespace|Show
15namespace SomeLibrary {/*...*/};
22
23void Report(const Character& Input) {
24  SomeLibrary::LogHealth(
25    const_cast<Character&>(Input)
26  );
27}
28
29int main() {
30  Character Player;
31  Report(Player);
32}

1Health: 100

1int x { 5 };
2int& Reference { x };
3
4const int& ConstantReference {
5  const_cast<const int&>(Reference)
6};

mutable Members

Within our classes, we can mark some variables as mutable. Mutable variables can be modified by const member functions.

The use case for this is inherently quite niche and, oftentimes, using it at all indicates a flaw with our design. This is particularly true if we're marking variables that are core to the functionality of our class mutable.

However, it can sometimes be helpful for scenarios where our objects carry ancillary data that is not part of the public interface.

Below, we would like to keep track of how many times consumers have checked the health of our object, so we introduce a private member variable and increment it from GetHealth():

1class Character {
2public:
3  int GetHealth() const {
4    HealthRequests++;
5    return Health;
6  }
7private:
8  int Health { 100 };
9  int HealthRequests { 0 };
10};

Naturally, the compiler prevents this, as GetHealth() is const, and we can’t modify our object from a const function:

1error  'HealthRequests' cannot be modified because it is being accessed through a const object

We could make GetHealth() non-const, but that could be quite disruptive, requiring us to make lots of Character references around our code base non-const too.

Additionally, it would be a confusing change for consumers. Whilst GetHealth() is indeed modifying the object, it’s not modifying it in a way that consumers should ever care about.

So, instead, we can simply mark the HealthRequests variable as mutable:

1class Character {
2public:
3  int GetHealth() const {
4    HealthRequests++;
5    return Health;
6  }
7private:
8  int Health { 100 };
9  mutable int HealthRequests { 0 };
10};

Summary

This lesson introduces the concept of const-correctness, exploring how const can be used with variables, functions, and pointers to prevent unintended modifications.

Key Takeaways:

• Understanding the difference between pass-by-value and pass-by-reference, and how const can be used to avoid modifications to the original object when passed by reference.
• Learning about const member functions and how they ensure member methods do not modify the object, allowing their use with const objects.
• Differentiating between const pointers and const objects, including various combinations like const pointer to const and const pointer to non-const.
• Grasping the concept of compile-time constants (constexpr) versus runtime constants (const) and their respective uses.
• Recognizing appropriate contexts for using const and understanding advanced concepts like const_cast and mutable members.

Preview of the Next Lesson

In the upcoming lesson, we will delve into some commenting best practices. Additionally, we'll introduce comment formats like Javadoc, which makes our comments more powerful.

Key Topics Covered:

• Learning best practices for writing effective comments.
• Techniques for avoiding over-commenting and maintaining a balance between code and comments.
• Practical examples of how to apply commenting best practices in real-world coding scenarios.
• Introduction to Javadoc-style commenting and its benefits.

Next Lesson

Effective Comments and Javadoc

This lesson provides an overview of effective commenting strategies, including Javadoc style commenting for automated documentation

ContinueView Course