Understanding Move Semantics and Perfect Forwarding: Part 3



Perfect Forwarding and Everything Else

In the previous article I introduced rvalue references and discussed how they can be used to improve performance of C++ applications using move semantics. In this final article we will look at how rvalue references improve the flexibility of C++ code when writing template programs using perfect forwarding.

What is Perfect Forwarding

Perfect forwarding allows a template function that accepts a set of arguments to forward these arguments to another function whilst retaining the lvalue or rvalue nature of the original function arguments.

Perfect forwarding reduces excessive copying and simplifies code by reducing the need to write overloads to handle lvalues and rvalues separately.

Note: The function the arguments are forwarded to can be a normal function, another template function, or a constructor.

template<typename T>
void OuterFunction(T& param)

Without having written template code in C++ before this might not make a whole lot of sense so above is an example of a template function that forwards its argument param to another inner function.

Notice that the outer function accepts an lvalue reference, therefore we can only pass into it lvalues, the following code will not compile.

OuterFunction(5); // Wont work trying to pass an rvalue to lvalue reference

To fix this we could make the outer function accept a const lvalue reference to allow us to pass rvalues but then the inner function would not be allowed to modify its argument. Instead we would have to write an overload of the outer function that handles rvalues.

template<typename T>
void OuterFunction(T&& param)

More importantly what if our inner function must accept an rvalue reference as an argument. From the previous article we know that an rvalue reference is in fact treated as an lvalue so even if our outer function accepts an rvalue reference when it comes to passing that argument to the inner function it will be seen by the compiler to be an lvalue and is therefore not allowed.

The problems mentioned above plus many other issues that can crop up when writing template code is what perfect forwarding solves. However, to truly understand perfect forwarding several other concepts must first be understood.

Template Type Deduction

void OuterFunction(T&& t) {

Template type deduction relates to how the compiler deduces the type T passed into the template function when the functions parameter is of type T&&. Two rules govern how T is resolved that depends on whether the argument passed is an lvalue or rvalue. The rules are as followed:

  1. If the argument passed to T is a lvalue, then T is deduced to a lvalue reference, X&
  2. If the argument passed to T is a rvalue, then T is deduced to a lvalue X.

Basically, we can call a template function without having to specify the type T being passed and have the compiler determine the type itself with the rules above governing what the type T value becomes in respect to its expression value. The type of T is deduced from the argument passed into the function call.


If the above call was made the compiler would determine the type T as an int and given that an rvalue is being passed the expression value of T would be an lvalue,  T = int.


If the above call was made the compiler would determine the type T as a string and given that an lvalue is being passed the expression value of T would be an lvalue reference. T = string&.

Note: type deduction occurs when the type is not known and therefore must be deduced, so in the case of OuterFunction(“Hello”); would not compile as the function excepts an lvalue reference of type string which an rvalue “Hello” cannot be bound to.

Reference Collapsing

Reference collapsing is a set of rules in C++ 11 to determine the value of T of a template function argument when trying to take the reference of a reference which is something that is illegal in C++. Taking the address of an address doesn’t make any sense but it can sometimes occur when writing templates.

template<typename T>
void func(T t) {
T& k = t;
string hello = “Hello”;

In the above example the type T is deduced to int& and then we are trying to store a reference to t in the form of k which means we are trying to do (int&)& k = t. Trying to take a reference to our reference.

Therefore, reference collapsing rules states what the value of T is dependent on the type of referencing that is occurring:

  • Taking the reference of an lvalue reference results in an lvalue reference X& & becomes X&
  • Taking the rvalue reference of an lvalue reference is an lvalue reference X& && becomes X&
  • Taking the lvalue reference of an rvalue reference is an lvalue reference X&& & becomes X&
  • Taking the rvalue reference of an rvalue reference is an rvalue reference X&& && becomes X&&

In any situation where an lvalue reference is involved the compiler will always collapse the type to an lvalue reference, if an rvalue references is involved then the type deduced is an rvalue reference.

Forwarding with forward

The function std::forward is required for solving the perfect forwarding problem with the functions purpose to resolve that awkward rule in which rvalue references are treated as lvalues (see the last article for more information).

The problem this causes is that even when passing an rvalue to a function that accepts an rvalue reference given that the rvalue reference parameter is treated as an lvalue reference we cannot then forward this to a function that accepts an rvalue. We have lost all the benefits move semantics gives us.

This is where std::forward comes in as it does two things dependent upon the value that is passed to the function:

  1. If passed an argument that isn’t an lvalue reference e.g. int& val, then it will return an rvalue reference.
  2. If an argument passed in an lvalue reference the function returns an lvalue reference, it does nothing to the argument.

This means that passing in an rvalue to a template function that accepts an rvalue reference will be able to forward that argument as an rvalue to any inner functions and if an lvalue is passed and we have an overload for our inner function that accepts lvalues then that function is called instead.

Universal References

The differences between a universal reference and an rvalue reference is that although it is denoted using ‘&&’ it doesn’t have to be an rvalue reference, it can sometimes mean ‘&’, be an lvalue reference.

As will be shown later this is how we can pass lvalues and rvalues to a template with a parameter of type T&& without the compiler complaining. The previous article referred to how a function with an rvalue reference can only accept rvalue references and that is true because in the context of a normal function ‘&&’ means rvalue reference. With template functions T&& can mean T&& or it can mean T&.

In general, ‘&&’ means a universal reference only when template type deduction is involved which is not the case if we are using a non-template function. With the advent of a new reference type there is unfortunately more rules that need to be learned:

  • If the expression initializing a universal reference is an lvalue, the universal reference becomes an lvalue reference.
  • If the expression initializing the universal reference is an rvalue, the universal reference becomes an rvalue reference.

Bringing it all Together, Perfect Forwarding

Bringing all the above rules together brings us what is referred to as perfect forwarding. A set of rules and functions within C++ that provide us with the ability to pass a value regardless of whether it is an lvalue or an rvalue and have that value preserved when being passed to a function called within a template function.

Below is a simple example of perfect forwarding where an object of type A has its constructor called within a template function, with the move constructor, or copy constructor being called dependent on the value passed to template function.

class A
A(std::string b) : b(b) {}

// Copy Constructor
A(const A& other) : b(b)
b = other.b;
std::cout << "Copy Constructor" << std::endl;

// Move Constructor
A(A&& other)
b = std::move(other.b); std::cout << "Move Constructor" << std::endl;
std::string b;
//And a template function
template<typename T>
void OuterFunction(T&& param)
A a(std::forward(param));
// Passing an lvalue
A a = A("Hello");

// Passing an rvalue

After researching around on the internet I couldn’t find an answer that definitely explained how std::forward works but this post explains std::forward in the context of perfect forwarding.  Basically, std::forward returns a static_cast(t) when T is explicitly defined and t is our passed parameter.

template<typename T>
void func(T&& t) {

If we let the template parameter be defined as a universal reference T&& then std::forward is either going to be passed an lvalue reference or an rvalue reference. Given std::forward is basically a static_cast(param) where T is explicitly defined not deduced then reference collapsing rules determine the returning value where static cast looks either like static_cast<A& &&>(param) or static_cast<A&& &&>(param).

Passing an Lvalue

Looking at the above example we can look at how everything we discussed comes into practice. Passing the variable ‘a’ to OuterFunction which is an lvalue means that the type T is deduced to A&.

Next, given that the param now looks like A& & as universal reference rule states that if an lvalue is passed T&& is treated as an lvalue reference.  For param we can look at the reference collapsing rules to determine that param A&, is an lvalue reference.

Finally, param is passed to std::forward and the static cast of std::forward returns an lvalue reference due to the reference collapsing rules.

In this instance an lvalue reference is passed to ‘a’ and thus the copy constructor is invoked.

Passing an Rvalue

Passing the object A(“World”) an rvalue expression to OuterFunction results in T being deduced to A.

Next, given that param now looks like A && where the universal reference is treated as a rvalue reference, so we just get A&&.

Finally, param is passed to std::forward and the static cast of std::forward returns an rvalue reference due to the reference collapsing rules.

In this instance an rvalue reference is passed to ‘a’ and thus the move constructor is invoked and we can take advantage of move semantics avoiding an unnecessary copy of member variable ‘b’.

Step by Step Guide

To summarise, for perfect forwarding to work it requires that a template function accept a parameter of type T&& and that template type deduction is used. As well as this std::forward must have its type explicitly defined.

  1. The argument passed to a template function first has its type deduced, which results in an lvalue or an lvalue reference. T becomes T& or T
  1. Because a universal reference is being used if the expression passed to the function (the argument) is an lvalue then T&& param becomes T& param, if its an rvalue it becomes T&& param referring to an rvalue reference.
  2. At this point we have either (T& && param) or T && param and reference collapsing rules are applied so the parameter to the function results in either an lvalue reference or an rvalue reference.
  3. Finally, given that an rvalue reference is in fact treated like an lvalue reference std::forward is required to cast the template parameter to the correct value. Again, reference collapsing rules are required that determines if we have an lvalue reference then an lvalue reference should be forwarded and if we have an rvalue reference our value should be cast to an rvalue reference.


Admittedly when I first started writing this article I didn’t quite realise how complicated perfect forwarding was and how many subtle behaviours of C++ was required to fully comprehend what was going on. After all I still don’t fully understand std::forward and I can’t guarantee that what I have wrote is 100% correct but I think it makes sense. Either way  I hope this article and the previous two have provided enough information to emphasise the need and practical uses of rvalue references, move semantics and perfect forwarding within C++ 11.

Further Resources




Understanding Move Semantics and Perfect Forwarding: Part 2



Rvalue References and Move Semantics

In the previous article I discussed lvalues and rvalues, what they mean and how they can affect a developer’s ability to write C++ applications. In this article I will take it a step further and finally introduce rvalue references, and how knowledge of rvalues are required for implementing move semantics.

We looked at how passing arguments by reference was important for performance, yet this imposed limitations. Only lvalues could be passed by non-const reference, and rvalues could be passed if the reference was const, meaning that the value couldn’t be modified.

As C++ 11 introduces the concept of rvalue references, the references we looked at previously are commonly referred to as lvalue references. An lvalue reference can be assigned a modifiable (const) lvalue or an unmodifiable value, and if the lvalue reference is defined as const (unmodifiable) they can be assigned an rvalue.

An rvalue reference is a reference that is only assigned an rvalue, meaning you cannot pass an lvalue to a function that has an rvalue reference argument. Below is an example of an rvalue reference, denoted with a double ampersand ‘&&’.

int &&rvalueRef = (x+1); // rvalueRef is rvalue reference

Having the ability to use rvalue references in C++ 11 opens up the ability to use rvalues in ways that were not previously possible as shown in the following code:

string Hello()
    Return “Hello World”;
string &&rvalRef = Hello();
rvalRef = “Hello”;
std::cout << rvalRef << std::endl; // Outputs “Hello”

The above code highlights how rvalue references change the way we interact with rvalues. Firstly, rvalues are no longer restricted to live only within the expression they are defined.  An rvalue’s lifetime becomes linked to the rvalue reference, and will therefore exist until that reference expires.

Prior to C++ 11 we could extend an rvalues lifetime by passing it to an un-modifable lvalue reference, however in this case the rvalue was un-modifable. With rvalue references, the rvalue can now be modified.

Now we are finally here, we understand rvalues, lvalues, lvalue references, and rvalue references. We are almost at the point of learning about move semantics, but first we need to make sure we have an understanding of temporary objects otherwise move semantics are not going to make much sense.

Temporary Objects

A temporary object is an object created during the creation of an expression and its purpose is to provide a temporary location for the result of that expression. Without temporary variables we would have to define variables to store these results. This was covered in more detail in the previous article.

It is worth remembering that an expression in C++ is any piece of code that returns a value, so there are many times within a C++ application that temporary objects are created, some examples include:

  • Returning a value from a function
  • Literals
  • Implicit conversions
  • Passing by value to a function

The reason why we are talking about temporary objects is because they are rvalue expressions, and whenever a temporary object is created, memory is allocated for that object, and the result from an expression is copied into it. The act of copying data into temporary objects is what can cause seemingly hidden performance issues within a C++ application, and are what move semantics aim to address.

Move Semantics

Move semantics aim to avoid the copying of data from temporary objects by instead stealing the memory location of where the object resides. This behaviour is implemented through the use of a move constructor and move assignment operator that act only on rvalue references.

MyClass(MyClass&& other)
_buffer = other._buffer;
_length = other._length;

other._buffer = nullptr;
other._length = 0;

In the above move constructor the following things occur. An rvalue reference argument is defined, so that the function only accepts rvalues like temporary objects. Given that _buffer is a raw pointer to an array, the _buffer pointer is simply assigned to point at the location of our temporary object and _length is updated to store the _length of other._buffer.

Finally, the rvalue reference other is reset to its default value. Assigning other._buffer to nullptr ensures that our temporay object no longer points to this data. This is important as we previously mentioned the lifetime of the temporary object is linked to the life time of the rvalue reference, which expires at the end of the move constructor. When the temporary object is being destroyed, like any other object its destructor will be called which would free up all the memory it was allocated i.e. our _buffer array.

The result of this move constructor is that we have now copied our object without having to copy any data, we have essentially just stolen the address of the temporary object instead.  For reference, below shows how a move assignment operator would look.

MyClass& MyClass::operator=(MyClass&& other)
    if(&other != *this)
delete[] _buffer;
_buffer = other._buffer;
_length = other._length;

other._buffer = nullptr;
other._length = 0;

A move constructor and move assignment operator can only be passed rvalues, whenever an lvalue is used, the copy constructor, or copy assignment operator will be called which means data will simply be copied to the new instance of the object. If we want to treat an lvalue like an rvalue so we can make use of move semantics then we need to cast an lvalue to rvalue.


In addition to the things already discussed, C++ 11 introduces a method std::move, that allows casting an lvalue to an rvalue. The method does not move the data, that is done by the move constructor, but by converting the lvalue to the rvalue it allows move constructor to be called.

std::string hello = “Hello World”; // lvalue

std::string(hello); // hello an lvalue so copy constructor called

std::string(std::move(hello)); // cast hello to an rvalue allowing move constructor to be called

Caution must be taken when using std::move. When working with a temporary object if we pass it to a move constructor we know that the temporary object (the rvalue reference) is going to cease to exist once method has finished being executed. With an lvalue, its lifetime might not be so short and by using std::move and essentially treating it like a temporary object we could end up deleting data that is used somewhere else in the program.

Therefore, it is wise to only use std::move on lvalues that we know aren’t going to get used anywhere else in the code, such as if they are local to the function in which a move constructor is being called.

Rvalue References are Lvalues

We now know that if we want our move constructor or move assignment operator to be called we must ensure we are passing an rvalue or first casting lvalue to an rvalue with std::move. It might not be apparently obvious but we can still end up calling the copy constructor if we are not careful.

MyClass(MyClass&& other)
_buffer = other._buffer;
_length = other._length;
_name   = other._name;

other._buffer = nullptr;
other._length = 0;
other._name = "";

In the above code we have modified the class MyClass to store a string object and updated our move constructor to accommodate this change. At first it might seem that when we execute _name = other._name we are calling the move constructor of string when in fact we are actually calling its copy constructor.

The copy constructor is being called because when an rvalue is passed to an rvalue reference this value is in fact an lvalue. This makes sense given the definition of an lvalue. A value that has an identifiable location in memory which you can get the address of. If the rvalue reference is in fact an lvalue then the objects copy constructor will be called because we are passing it an lvalue. To ensure the move constructor is called we must use std::move, this is safe because the original object being passed in should be a temporary object or an lvalue we know has limited lifetime.

MyClass(MyClass&& other)
_buffer = other._buffer;
_length = other._length;

// None primitive types will have their copy constructors called unless we first cast them to an rvalue.
_name = std::move(other._name);

other._buffer = nullptr;
other._length = 0;
other._name = "";


Hopefully you now have a good understanding of rvalue references, move semantics, and how move semantics are useful for improving the performance of C++ applications by avoiding the need to copy data when we temporary objects are involved.

Fortunately for us, move semantics are supported in modern C++, meaning the standard library has been updated to include move constructors and move assignment operators for all objects and can support any user defined objects that contain their own.

In addition, move constructors and move assignment operators will be implicitly created unless the user defines: a copy constructor, copy assignment operator, or destructor. So as long as we are not handling resources with raw pointers, or requiring deep copies of objects that rely on a custom copy constructor, we can happily reap the benefits of move semantics without making changes to our code.


Understanding Move Semantics and Perfect Forwarding: Part 1



An Introduction to Rvalues and Lvalues

With the introduction of C++ 11 comes the ability to further improve the performance and flexibility of C++ applications thanks to the introduction of move semantics and perfect forwarding. Two concepts that rely on rvalue references.

Before discussing these new concepts an understanding of rvalues and lvalues is required. These concepts are themselves not too difficult, but the evolving nature of C++ and the changes in definition of these values as the language has matured can make them rather confusing for new developers.

At the beginning rvalues and lvalues were defined in such a way that an rvalue very simply meant something that appeared on the right-hand side of an assignment, and an lvalue on the left. For example:

int num = 3;

4 = num; // 4 is a literal which is an rvalue and num is an lvalue thus the following code isn’t valid

But something like the following is acceptable:

int num = 4; // num is an lvalue and 4 is an rvalue

As time moved on and the C++ language evolved, so too did the definitions of rvalues and lvalues. Unfortunately, their names did not evolve with it. In more modern versions of C++ rvalues and lvalues took on new meanings.

Lvalues and rvalues became something used to describe the results of an expression (An expression being any code that returned a value) and as such an expression would be described as either an lvalue expression or an rvalue expression.

To the compiler this defines amongst other things how the result of an expression is stored. To a developer, which I am assuming you are, it basically means that the lvalue has a name and an identifiable location in memory that can be accessed using ‘&’. An rvalue is something that does not have an identifiable location in memory and thus it cannot be accessed with ‘&’.

An easy way to identify whether an expression returns an rvalue or an lvalue is to determine if you can take address of the value. If you can its an lvalue otherwise it’s an rvalue.

Rvalues are temporary and have short lifetime where they exist within the expression they were created. Because of this C++ doesn’t allow access to them through the address of operator due to the amount of problems it could occur by trying to access the address of short lived data.

That about wraps it up for what rvalues and lvalues are, but I can assume that the above definition does little to explain their actual use in writing of C++ applications. I will attempt to amend this in the next section by explaining how they can cause issues when writing code.

As previously mentioned you cannot obtain the address of an rvalue because C++ won’t allow it. This means that when writing code there are a lot of values that we cannot have references to. Literals, functions that return by value, and temporary objects are just a few examples. This means that a reference cannot be stored to these values, but more importantly these values cannot be passed to functions that accept reference types.

Unfortunately, passing by reference is a common method of improving the performance of an application as it avoids the need to copy data between memory locations, which if there is a lot of data can take up too much time in our time critical applications.

Therefore, to avoid these issues we can take several steps. Simply try and avoid passing rvalues to functions which means the following code:

int sum(int& a, int& b) { return a + b;
Sum(3, 5);

Would have to be written as follows:

int sum(int& a, int& b) { return a + b;

int a = 5;
int b = 3;
int c = sum(a, b);

The convenience of using rvalues is lost to maintain performance but at the cost of readability and time. A second option is to pass by value but that could potentially mean hindering performance. A third option exists, and that is to pass by reference but making the parameter of a function const.

int sum(const int& a, const int& b) { return a + b;
Sum(3, 5);

C++ allows an rvalue to be assigned to a reference which is an lvalue if and only if that lvalue is defined as const which stops it from being manipulated. This means the rvalue is technically an lvalue within the scope of the function, and the function is now able to accept rvalues whilst still preserving pass by reference.

An obvious problem that arises is that if a function needs to manipulate a reference then it can’t without overloading that function with a non const variant when wanting to pass an lvalue. Rvalues bring up additional problems in C++ which weren’t addressed until C++ 11.

For instance, C++ has a tendency to overindulge when it comes to copying values and there are issues with forwarding values to functions called within template functions. These issues are combated with move semantics, and perfect forwarding which will be a lot easier to understand now that you have an understanding of rvalues and lvalues and will be the focus of the next couple of articles.

Tricky C++: Making Things Constant

C++ is a confusing language that is difficult to write and in some ways even more difficult to read, especially if a developer doesn’t follow good programming practices. One way of writing better C++ code is to make use of the const keyword. Const enforces the policy of un-modifiability and can be used in conjunction with both variables and class methods.

Const Variables

A constant variable is a variable that cannot be altered, and must be initialised when declared because it cannot be changed later on! The following is an example of a const variable.
​The syntax for a constant variable is similar to that of any other variable, bar the introduction of the const keyword that is added before defining the type of the variable.
Note: A constant reference acts like a const variable except the address stored in a reference points to data that cannot be modified as opposed to storing the unmodified data itself.

Const Pointers 

Any type in C++ can be defined as const, including pointers. In the case of a pointer the position of the const keyword has a different meaning. The code below shows different ways in which const is applied to a pointer.

The above example shows the three different ways in which const can be applied. Applying const anywhere before the ‘*’ states the data located at the memory address stored by the pointer must be constant. In this case the pointer has to point to data that is defined as constant.

Applying const after the ‘*’ states that the pointer itself is const, i.e. the address stored in the pointer cannot be altered, which also means the pointer must be initialised when declared.

Note: A pointer with a constant address can be compared to a reference, as a reference cannot alter the address it stores after it has been initialised.

Const to non -const 

There is one final issue with regards to const that needs to be addressed, regarding the assignment of a const variable to a non const variable. A variable that is constant cannot be assigned to variable that isn’t defined as constant if the assignment copies the address of the value, and not the data itself.

Assigning data from one variable to another involves copying the data, and storing it in a new memory location. Because of this when the new variable modifies the data it is modifying its own copy and not the original data defined as constant, so the original data remains unchanged. Whereas passing the address of constant data to a variable that isn’t defined as constant would give that variable permission to modify the data, which was defined as unmodifiable. This would defeat the purpose of defining the original variable as constant.

Const Methods

Additional to variable constness, const can be applied at the end of a class method and will enforce that the object will not be altered in this function, i.e. the data members of the object cannot be changed.  There are few rules regarding the use of const:

  1. Const methods can be called by non const objects because defining a method as const simply states that member data won’t be changed. The object calling the data may still want to change its members in a different method.
  2. Defining an instance of an object as const, and therefore unmodifiable, means that only const methods can be called by that object. Again if the object is defined as constant then calling non constant methods doesn’t make sense as these methods have the ability to alter the data of the object.
  3. A constant function can only return a constant value.

Note:  const is included in a function signature which means two methods can be produced, one const, and one not dependent on the object calling the method.

Consts in Use

The use of const within C++ is a tool to make code easier to read, which in turn can help with maintainability. There are several different ways in which constant values can help achieve this.

The most common example of using const is to define a set of values as const which will be unchanged but used extensively through a program. If there is a case where the same value is used repeatedly throughout, it is better to establish that value as a constant and then use the variable throughout the code instead. The result of this is that fewer errors can be made because the value is being written only once, when the variable is initialised. Secondly if the const value does need to change this only needs to occur in one location. Finally, it is easier to read a program that contains constants, than simply values, because they are named, and because in some cases a programmer might use values that are not commonly known, and this can make it difficult to understand their purpose.

Note: consts variable names are usually made capital e.g. pi becomes PI, which makes it easier to identify these values within a program.

The use of constentness helps clarify the intended use of a variable or method. Defining a parameter or return type as constant means that the values being used in a function or returned by that function are not to be modified. A const method tells someone that this function was not created with the intention of altering the members of a class. Any lack of understanding that results in an attempt at altering a constant value will cause the compiler to complain, so a programmer has no way of mishandling the piece of code.

A final example is the use of const to help with encapsulation. To summarise, encapsulation refers to hiding data and methods from other classes and is used to ensure no unauthorised manipulation occurs to the class. A classes interface defines the behaviours the class carries out, and these behaviours establish how, if possible, the data a class stores can be manipulated. By not hiding data or certain methods in a class an outsider could cause issues such as assigning an unwanted value to a variable that could cause errors, for instance assigning a zero to a value that is used within a division.

The use of const can help enforce the concept of encapsulation, specifically when using Getter methods within a class. A value returned “by value” from a Getter does not break encapsulation as a copy of the data stored in the class is being manipulated and not the original. However, if an address is returned instead, then objects outside of the class have the ability to manipulate the data stored within the class, which does break encapsulation.


To summarise, this article has provided overview of the const keyword, how it can be applied to variables, and methods, as well as providing examples of how const can help create more readable C++ code.

  • using const on a variable means its data cannot be altered.
  • const pointers can mean the data cannot be altered, the address the pointer stores cannot change, or both.
  • A constant pointer or reference cannot be assigned to a non-constant value because that would allow the data stored at the address to be changed
  • Using const with class methods prevents that method from altering the data members of the class.
  • Const makes C++ code more readable and should be used as an alternative to literals if they are used extensively within a program and do not change.
  • Using const helps definition the intentions of a variable or method
  • Having constant return values within Getter methods helps enforce encapsulation by ensuring the returned value cannot be altered from outside the class.

Tricky C++: Making Memory Management Easier with Smart Pointers

One of the problems with writing programs in C++ is that using dynamic memory can be troublesome as it requires manually managing the allocation and deallocation of the memory you want to use. Unfortunately, dynamic allocation is an important feature in C++ and is required when using virtual functions, for polymorphic behaviour. Dynamic allocation is also required if you intend to store data that is larger than the stack (over 1MB), or of an unknown size at compile time, for instance, data received as input from a user. There are other benefits such as allowing the creation of dynamic data structures, and allowing objects to exist beyond their original scope.  Also did I mention you have to use pointers when allocating memory dynamically.

The problems that occurs with dynamic allocation relates to the manual memory management as mentioned previously. Two important issues that can arise are dangling pointers and memory leaks. The former refers to an instance in which a pointer attempts to access memory that has previously been freed. The latter relates to forgetting to deallocate memory leaving it inaccessible and unusable during the execution of the program. If this is done repeatedly, the amount of memory available to other programs reduces, eventually causing instability and crashes of the system. Therefore, there is a significant risk involved in using dynamic memory, however it is sometimes unavoidable. With the release of C++ 11, came the introduction of smart pointers, a feature that makes it easier to handle dynamic memory.

Smart Pointers

​Smart pointers avoid manual memory management by automatically managing the memory for you. They can be a little more confusing to understand than raw pointers, mainly due to their being several different types: shared, weak, and unique pointers. The difference between these pointers is in the type of ownership semantic they implement. Remember that one way of helping to reduce memory management issues is to define who owns the object so that it is the owner, and just the owners responsibility to handle the creation and destruction of the object.


A unique pointer (unique_ptr) is a smart pointer that has exclusive ownership semantics. What this means is that the resource can only be owned by the unique pointer, and when this pointer goes out of scope, the resource is released. The only way for a unique_ptr to “share” the resource is to transfer ownership of that resource using the move semantic.

A shared pointer (shared_ptr) uses the concept of shared ownership semantics. Multiple shared pointers can refer to a single object, when another shared pointer refers to a resource, a reference count is increased. Only when the last shared pointer goes out of scope, is the memory released.

weak pointer (weak_ptr) acts like a shared pointer in that it provides sharing semantics, however a weak pointer does not own the resource. Meaning that someone else, a shared pointer, must already own a resource that weak pointer can share. Furthermore, the number of weak pointers do not contribute to the reference count of a resource, therefore a resource will be released even if weak pointers still share that resource. This means that a weak pointer cannot access the object it shares. In order to do so a shared pointer must be created from this weak pointer.The reason this is done is so that the resource cannot be destroyed whilst being used by the weak pointer because there will be at least one shared pointer accessing the resource. This does not prevent a weak pointer from accessing a resource that no longer exists.


This all well and good though but you may be asking when should you use each pointer. Well like most of programming it depends. However understanding the ownership semantics of each type goes a long way.

​A unique pointer is meant solely for single ownership. For example, if you were to have an engine class that had the responsibility of creating and initialising the subsystems of an engine, like the renderer, or physics system. Then it is not unreasonable to assume that the Engine class would be the sole owner of each subsystem and would store each in a unique pointer. When the Engine class is destroyed which would typically be when the game using it is closed, then all the subsystems would be shut down, and the resources related to these systems freed when the instance of Engine goes out of scope. Although ownership remains with Engine, the subsystems can still be accessed by other parts of the game engine by referring to the pointer stored by the unique pointer, accessed through the get() function. This allows other objects access to the resource, the desired system.

A weak pointer doesn’t have ownership but has the ability to share a resource and can be constructed to share the resources of a shared pointer, not a unique pointer. Therefore, a weak pointer can be useful in situations involving shared pointers where you don’t want a function or class accessing the resources of the shared pointer to also control ownership of the resource. Going back to the idea of a game engine again. If we were to have a game object class that stored a list of all the components attached to it, suppose we wanted the components to communicate with other components in the same game object. One idea would be to allow the component to hold a reference to the its parent, the game object. This reference could be stored as weak pointer because it doesn’t make sense for the component to be able to destroy the game object, its parent The game object would most likely have ownership over the components, and these components would be destroyed before the game object.

​A shared pointer can be used in situations in which a unique or weak pointer are implemented except for when using them causes a cyclic dependency. This relates back to the second example with game objects and components. If we have a shared pointer in game object that stores a component, and a component stored in the game object holds a shared pointer to the game object, its parent as shown below.

In the example shown above neither the spaceship or laserWeapon objects will be deleted. When both objects are created a reference count of 1 is set for both. When gameObject holds a reference to laserWeapon the reference count is incremented to 2, and the same occurs when laserWeapon holds a reference to spaceShip. When the program reaches the end of main both objects will go out of scope, and thus the reference count for both is reduced to 1 because we have lost one owner.  laserWeapon’s reference count won’t hit 0 until spaceShip’s reference count hits 0, and vice versa, creating a circular dependency that results in the memory of both never getting deleted. Neither reference count hits 0, so C++ doesn’t think that the memory has to be deallocated.

Tricky C++: An Introduction to Pointers




Pointers are prevalent throughout C++ and it is important to understand them in order to take advantage of many of features that exist in C++. However, for a beginner, they can be rather tricky to grasp, especially given how confusing the syntax can be. This article attempts to alleviate the pain of learning pointers,  by explaining what they are, how to use them, and why we would use them.

What is a Pointer?

A pointer is a variable that stores the memory location instead of the data itself. The basic syntax for a pointer looks like the following:

The above syntax shows a typical example of how to declare a pointer. The address-of operator ‘&’ is used to obtain the address of the data stored in the variable a, and it is that address that is stored in ptr. Although our pointer stores a memory address it is still necessary to declare the type of data that the memory address stores, so that the pointer can be used to manipulate the data.

Note: The ‘*’ operator is used to declare that the variable is a pointer, the position of ‘*’ can be positioned int* pointer or int *pointer, however the former declaration can be slightly confusing as it mimics the syntax required to dereference (explained next) a pointer.

Dereferencing a Pointer 

As previously mentioned a pointer stores the memory location and not the data, therefore a pointer is pretty useless at using that data unless you can gain access to it. Dereferencing does exactly that, and provides a way for you to access the data stored in the memory location of a pointer. Dereferencing ptr looks like the following:
 In this example we use the dereference operator ‘*’ (yes, it is the same operator used for declaring a pointer) to gain access to the data stored at the address it points to, in this case it is the value 12. The value is stored within a variable b and is then used in a simple expression.

Note: Care must be taken when more than one pointer holds the address to the same data. Altering the data with one pointer reference in one part of your code will affect the data being used by all the others, and this can cause undesired behaviour.

Object Pointer

So far pointers have been described using C++ fundamental types, however pointers can be used to store the address of an object. The syntax is just a little bit trickier when accessing member data or methods. The following example shows one way of using a pointer with an object of type Student.
The second statement dereferences the pointer containing the address of the object, and then uses the dot operator to access the member function GetMathMark(). Without the parenthesis, the statement would first try to access the method of the object and then attempt to dereference, due to the operator precedence defined in C++. Given that the pointer stores an address and not the type Student this would not work out well. The syntax can be rather troublesome, therefore there is an alternate way which uses the “->” operator, which allows pointer to member access, and removing the need for parenthesis.

​Pointer to a Pointer 

Another aspect of pointers is that they are able to store the address of other pointers. Yes, pointers can store the address of a pointer, which the pointer of the address it stores points to the address of some data. An example is shown below using C++ fundamentals, but this also works on user-defined types.
pointer as pointeroutput2
In this case, pptr is initialised with the address of ptr not the address of the variable a, and a can be accessed by either dereferencing ptr using a single “*” or through pptr using two “*”. ​As you can see the syntax for a pointer to a pointer is similar to that of a normal pointer, with the exception of an additional “*” in both the pointer declaration and when dereferencing.

When a Pointer is Required

So now the basics of pointers has been explained, the next question is why do we need pointers? Pointers are used extensively in C++, and below are a few examples, with no emphasis on describing any particular use case, as each could be an article of their own.

  • Polymorphism
  • Dynamic allocation
  • Efficient parameter passing (Although it is better practice to use references)
  • Function pointers

​Therefore, as you can see pointers are required if you want to make the most of C++, and make use of certain features of the language such as polymorphism, which is an important concept in any object orientated language.


To summarise, this article has introduced pointers in C++ and has provided a basic understanding of what they are, how they are used, and what they are used for.

  • A pointer holds the address of a variable, not the data itself.
  • The data stored at the memory address the pointer stores can be accessed by dereferencing the pointer.
  • A pointer can be used to store the address of an object, and requires parenthesising the object being dereferenced before using the member access operator, or using the “->” operator
  • Pointers can store the address of other pointers and is signified by the number “*” used when declaring and dereferencing a pointer