In C++, a common way of safely accessing resources is by wrapping a manager class around the handle, which is initialized when the resource is acquired (in the class constructor) and released when it is deleted (in the class destructor). This concept is often referred to as Resource Acquisition is Initialization (RAII), which we will discuss in greater depth in the next concept. One problem with this approach though is that copying the manager object will also copy the handle of the resource. This allows two objects access to the same resource - and this can mean trouble.
The simplest policy of all is to forbid copying and assigning class instances all together. This can be achieved by declaring, but not defining a private copy constructor and assignment operator (see NoCopyClass1 below) or alternatively by making both public and assigning the delete operator (see NoCopyClass2 below). The second choice is more explicit and makes it clearer to the programmer that copying has been actively forbidden. Let us have a look at a code example on the right that illustrates both cases.
On compiling, we get the following error messages:
error: calling a private constructor of class 'NoCopyClass1'
NoCopyClass1 copy1(original1);
NoCopyClass1 copy1b = original1;
error: call to deleted constructor of 'NoCopyClass2'
NoCopyClass2 copy2(original2);
NoCopyClass2 copy2b = original2;
Both cases effectively prevent the original object from being copied or assigned. In the C++11 standard library, there are some classes for multi-threaded synchronization which use the no copying policy.
class NoCopyClass1
{
private:
NoCopyClass1(const NoCopyClass1 &);
NoCopyClass1 &operator=(const NoCopyClass1 &);
public:
NoCopyClass1(){};
};
class NoCopyClass2
{
public:
NoCopyClass2(){}
NoCopyClass2(const NoCopyClass2 &) = delete;
NoCopyClass2 &operator=(const NoCopyClass2 &) = delete;
};
int main()
{
NoCopyClass1 original1;
NoCopyClass1 copy1a(original1); // copy c’tor
NoCopyClass1 copy1b = original1; // assigment operator
NoCopyClass2 original2;
NoCopyClass2 copy2a(original2); // copy c’tor
NoCopyClass2 copy2b = original2; // assigment operator
return 0;
}This policy states that whenever a resource management object is copied, the resource handle is transferred from the source pointer to the destination pointer. In the process, the source pointer is set to nullptr to make ownership exclusive. At any time, the resource handle belongs only to a single object, which is responsible for its deletion when it is no longer needed.
The code example on the right illustrates the basic idea of exclusive ownership.
#include <iostream>
class ExclusiveCopy
{
private:
int *_myInt;
public:
ExclusiveCopy()
{
_myInt = (int *)malloc(sizeof(int));
std::cout << "resource allocated" << std::endl;
}
~ExclusiveCopy()
{
if (_myInt != nullptr)
{
free(_myInt);
std::cout << "resource freed" << std::endl;
}
}
ExclusiveCopy(ExclusiveCopy &source)
{
_myInt = source._myInt;
source._myInt = nullptr;
}
ExclusiveCopy &operator=(ExclusiveCopy &source)
{
_myInt = source._myInt;
source._myInt = nullptr;
return *this;
}
};
int main()
{
ExclusiveCopy source;
ExclusiveCopy destination(source);
return 0;
}The class MyClass overwrites both the copy constructor as well as the assignment operator. Inside, the handle to the resource _myInt is first copied from the source object and then set to null so that only a single valid handle exists. After copying, the new object is responsible for properly deleting the memory resource on the heap. The output of the program looks like the following:
resource allocated
resource freed
As can be seen, only a single resource is allocated and freed. So by passing handles and invalidating them, we can implement a basic version of an exclusive ownership policy. However, this example is not the way exclusive ownership is handled in the standard template library. One problem in this implementation is that for a short time there are effectively two valid handles to the same resource - after the handle has been copied and before it is set to nullptr. In concurrent programs, this would cause a data race for the resource. A much better alternative to handle exclusive ownership in C++ would be to use move semantics, which we will discuss shortly in a very detailed lesson.
With this policy, copying and assigning class instances to each other is possible without the danger of resource conflicts. The idea is to allocate proprietary memory in the destination object and then to copy the content to which the source object handle is pointing into the newly allocated block of memory. This way, the content is preserved during copy or assignment. However, this approach increases the memory demands and the uniqueness of the data is lost: After the deep copy has been made, two versions of the same resource exist in memory.
Instead of copying the pointer directly to destination object, you can copy the content of the pointer, like *_myInt = *source._myInt;
The last ownership policy we will be discussing in this course implements a shared ownership behavior. The idea is to perform a copy or assignment similar to the default behavior, i.e. copying the handle instead of the content (as with a shallow copy) while at the same time keeping track of the number of instances that also point to the same resource. Each time an instance goes out of scope, the counter is decremented. Once the last object is about to be deleted, it can safely deallocate the memory resource. We will see later in this course that this is the central idea of unique_ptr, which is a representative of the group of smart pointers.
The example on the right illustrates the principle.
#include <iostream>
class SharedCopy
{
private:
int *_myInt;
static int _cnt;
public:
SharedCopy(int val);
~SharedCopy();
SharedCopy(SharedCopy &source);
};
int SharedCopy::_cnt = 0;
SharedCopy::SharedCopy(int val)
{
_myInt = (int *)malloc(sizeof(int));
*_myInt = val;
++_cnt;
std::cout << "resource allocated at address " << _myInt << std::endl;
}
SharedCopy::~SharedCopy()
{
--_cnt;
if (_cnt == 0)
{
free(_myInt);
std::cout << "resource freed at address " << _myInt << std::endl;
}
else
{
std::cout << "instance at address " << this << " goes out of scope with _cnt = " << _cnt << std::endl;
}
}
SharedCopy::SharedCopy(SharedCopy &source)
{
_myInt = source._myInt;
++_cnt;
std::cout << _cnt << " instances with handles to address " << _myInt << " with _myInt = " << *_myInt << std::endl;
}
int main()
{
SharedCopy source(42);
SharedCopy destination1(source);
SharedCopy destination2(source);
SharedCopy destination3(source);
return 0;
}Note that class MyClass now has a static member _cnt, which is incremented every time a new instance of MyClass is created and decrement once an instance is deleted. On deletion of the last instance, i.e. when _cnt==0, the block of memory to which the handle points is deallocated.
The output of the program is the following:
resource allocated at address 0x100300060
2 instances with handles to address 0x100300060 with _myInt = 42
3 instances with handles to address 0x100300060 with _myInt = 42
4 instances with handles to address 0x100300060 with _myInt = 42
instance at address 0x7ffeefbff6f8 goes out of scope with _cnt = 3
instance at address 0x7ffeefbff700 goes out of scope with _cnt = 2
instance at address 0x7ffeefbff718 goes out of scope with _cnt = 1
resource freed at address 0x100300060
As can be seen, the memory is released only once as soon as the reference counter reaches zero.
In the previous examples we have taken a first look at several copying policies:
- Default copying
- No copying
- Exclusive ownership
- Deep copying
- Shared ownership
Rule of Three states that if a class needs to have an overloaded copy constructor, copy assignment operator, or destructor, then it must also implement the other two as well to ensure that memory is managed consistently.
Rule of Three only applys to old C++ (prior to C++ 11)
A good grasp of lvalues and rvalues in C++ is essential for understanding the more advanced concepts of rvalue references and motion semantics.
Let us start by stating that every expression in C++ has a type and belongs to a value category. When objects are created, copied or moved during the evaluation of an expression, the compiler uses these value expressions to decide which method to call or which operator to use.
Prior to C++11, there were only two value categories, now there are as many as five of them:
To keep it short, we do not want to go into all categories, but limit ourselves to lvalues and prvalues:
- Lvalues have an address that can be accessed. They are expressions whose evaluation by the compiler determines the identity of objects or functions.
- Prvalues do not have an address that is accessible directly. They are temporary expressions used to initialize objects or compute the value of the operand of an operator.
For the sake of simplicity and for compliance with many tutorials, videos and books about the topic, let us refer to prvalues as rvalues from here on.
The two characters l and r are originally derived from the perspective of the assignment operator =, which always expects a rvalue on the right, and which it assigns to a lvalue on the left. In this case, the l stands for left and r for right:
int i = 42; // lvalue = rvalue;
With many other operators, however, this right-left view is not entirely correct. In more general terms, an lvalue is an entity that points to a specific memory location. An rvalue is usually a short-lived object, which is only needed in a narrow local scope. To simplify things a little, one could think of lvalues as named containers for rvalues.
In the example above, the value 42 is an rvalue. It does not have a specific memory address which we know about. The rvalue is assigned to a variable i with a specific memory location known to us, which is what makes it an lvalue in this example.
Using the address operator & we can generate an lvalue from an rvalue and assign it to another lvalue:
int *j = &i;
An lvalue reference can be considered as an alternative name for an object. It is a reference that binds to an lvalue and is declared using an optional list of specifiers (which we will not further discuss here) followed by the reference declarator &. The short code sample on the right declares an integer i and a reference j which can be used as an alias for the existing object.
#include <iostream>
int main()
{
int i = 1;
int &j = i;
++i;
++j;
std::cout << "i = " << i << ", j = " << j << std::endl;
return 0;
}The output of the program is
i = 3, j = 3
We can see that the lvalue reference j can be used just as i can. A change to either i or j will affect the same memory location on the stack.
One of the primary use-cases for lvalue references is the pass-by-reference semantics in function calls as in the example on the right.
While the number 42 is obviously an rvalue, with j+k things might not be so obvious, as j and k are variables and thus lvalues. To compute the result of the addition, the compiler has to create a temporary object to place it in - and this object is an rvalue.
#include <iostream>
void myFunction(int &val)
{
std::cout << "val = " << val << std::endl;
}
int main()
{
int j = 42;
myFunction(j);
myFunction(42);
int k = 23;
myFunction(j+k);
return 0;
}Output:
error: cannot bind non-const lvalue reference of type ‘int&’ to an rvalue of type ‘int’While the number 42 is obviously an rvalue, with j+k things might not be so obvious, as j and k are variables and thus lvalues. To compute the result of the addition, the compiler has to create a temporary object to place it in - and this object is an rvalue.
Since C++11, there is a new type available called rvalue reference, which can be identified from the double ampersand && after a type name. With this operator, it is possible to store and even modify an rvalue, i.e. a temporary object which would otherwise be lost quickly.
After creating the integers i and j on the stack, the sum of both is added to a third integer k. Let us examine this simple example a little more closely. In the first and second assignment, i and j are created as lvalues, while 1 and 2 are rvalues, whose value is copied into the memory location of i and j. Then, a third lvalue, k, is created. The sum i+j is created as an rvalue, which holds the result of the addition before being copied into the memory location of k. This is quite a lot of copying and holding of temporary values in memory. With an rvalue reference, this can be done more efficiently.
#include <iostream>
int main()
{
int i = 1;
int j = 2;
int k = i + j;
int &&l = i + j;
std::cout << "k = " << k << ", l = " << l << std::endl;
return 0;
}The expression int &&l creates an rvalue reference, to which the address of the temporary object is assigned, that holds the result of the addition. So instead of first creating the rvalue i+j , then copying it and finally deleting it, we can now hold the temporary object in memory. This is much more efficient than the first approach, even though saving a few bytes of storage in the example might not seem like much at first glance. One of the most important aspects of rvalue references is that they pave the way for move semantics, which is a mighty technique in modern C++ to optimize memory usage and processing speed. Move semantics and rvalue references make it possible to write code that transfers resources such as dynamically allocated memory from one object to another in a very efficient manner and also supports the concept of exclusive ownership, as we will shortly see when discussing smart pointers. In the next section we will take a close look at move semantics and its benefits for memory management.
The important message of the function argument of myFunction to the programmer is : The object that binds to the rvalue reference &&val is yours, it is not needed anymore within the scope of the caller (which is main). As discussed in the previous section on rvalue references, this is interesting from two perspectives:
- Passing values like this improves performance as no temporary copy needs to be made anymore and
- ownership changes, since the object the reference binds to has been abandoned by the caller and now binds to a handle which is available only to the receiver. This could not have been achieved with lvalue references as any change to the object that binds to the lvalue reference would also be visible on the caller side.
#include <iostream>
void myFunction(int &&val)
{
std::cout << "val = " << val << std::endl;
}
int main()
{
myFunction(42);
return 0;
}Note however that in the above code example we cannot pass an lvalue to myFunction, because an rvalue reference cannot bind to an lvalue. The code
int i = 23;
myFunction(i)would result in a compiler error. There is a solution to this problem though: The function std::move converts an lvalue into an rvalue (actually, to be exact, into an xvalue, which we will not discuss here for the sake of clarity), which makes it possible to use the lvalue as an argument for the function:
int i = 23;
myFunction(std::move(i));In doing this, we state that in the scope of main we will not use i anymore, which now exists only in the scope of myFunction. Using std::move in this way is one of the components of move semantics
Copy constructor, copy assignment operator, destructor.
#include <stdlib.h>
#include <iostream>
class MyMovableClass
{
private:
int _size;
int *_data;
public:
MyMovableClass(size_t size) // constructor
{
_size = size;
_data = new int[_size];
std::cout << "CREATING instance of MyMovableClass at " << this << " allocated with size = " << _size*sizeof(int) << " bytes" << std::endl;
}
~MyMovableClass() // 1 : destructor
{
std::cout << "DELETING instance of MyMovableClass at " << this << std::endl;
delete[] _data;
}
MyMovableClass(const MyMovableClass &source) // 2 : copy constructor
{
_size = source._size;
_data = new int[_size];
*_data = *source._data;
std::cout << "COPYING content of instance " << &source << " to instance " << this << std::endl;
}
MyMovableClass &operator=(const MyMovableClass &source) // 3 : copy assignment operator
{
std::cout << "ASSIGNING content of instance " << &source << " to instance " << this << std::endl;
if (this == &source)
return *this;
delete[] _data;
_data = new int[source._size];
*_data = *source._data;
_size = source._size;
return *this;
}
};
int main()
{
MyMovableClass obj1(10); // regular constructor
MyMovableClass obj2(obj1); // copy constructor
obj2 = obj1; // copy assignment operator
return 0;
}From a performance viewpoint, this code involves far too many copies, making it inefficient - especially with large data structures. Prior to C++11, the proper solution in such a case was to simply avoid returning large data structures by value to prevent the expensive and unnecessary copying process. With C++11 however, there is a way we can optimize this and return even large data structures by value. The solution is the move constructor and the Rule of Five.
The basic idea to optimize the code from the last example is to "steal" the rvalue generated by the compiler during the return-by-value operation and move the expensive data in the source object to the target object - not by copying it but by redirecting the data handles. Moving data in such a way is always cheaper than making copies, which is why programmers are highly encouraged to make use of this powerful tool.
The following diagram illustrates the basic principle of moving a resource from a source object to a destination object:
In order to achieve this, we will be using a construct called move constructor, which is similar to the copy constructor with the key difference being the re-use of existing data without unnecessarily copying it. In addition to the move constructor, there is also a move assignment operator, which we need to look at.
MyMovableClass(MyMovableClass &&source) // 4 : move constructor
{
std::cout << "MOVING (c’tor) instance " << &source << " to instance " << this << std::endl;
_data = source._data;
_size = source._size;
source._data = nullptr;
source._size = 0;
}MyMovableClass &operator=(MyMovableClass &&source) // 5 : move assignment operator
{
std::cout << "MOVING (assign) instance " << &source << " to instance " << this << std::endl;
if (this == &source)
return *this;
delete[] _data;
_data = source._data;
_size = source._size;
source._data = nullptr;
source._size = 0;
return *this;
}The Rule of Five states that if you have to write one of the functions listed below then you should consider implementing all of them with a proper resource management policy in place. If you forget to implement one or more, the compiler will usually generate the missing ones (without a warning) but the default versions might not be suitable for the purpose you have in mind. The five functions are:
- The destructor: Responsible for freeing the resource once the object it belongs to goes out of scope.
- The assignment operator: The default assignment operation performs a member-wise shallow copy, which does not copy the content behind the resource handle. If a deep copy is needed, it has be implemented by the programmer.
- The copy constructor: As with the assignment operator, the default copy constructor performs a shallow copy of the data members. If something else is needed, the programmer has to implement it accordingly.
- The move constructor: Because copying objects can be an expensive operation which involves creating, copying and destroying temporary objects, rvalue references are used to bind to an rvalue. Using this mechanism, the move constructor transfers the ownership of a resource from a (temporary) rvalue object to a permanent lvalue object.
- The move assignment operator: With this operator, ownership of a resource can be transferred from one object to another. The internal behavior is very similar to the move constructor.
-
One of the primary areas of application are cases, where heavy-weight objects need to be passed around in a program. Copying these without move semantics can cause series performance issues. The idea in this scenario is to create the object a single time and then "simply" move it around using rvalue references and move semantics.
-
A second area of application are cases where ownership needs to be transferred (such as with unique pointers, as we will soon see). The primary difference to shared references is that with move semantics we are not sharing anything but instead we are ensuring through a smart policy that only a single object at a time has access to and thus owns the resource.
int main()
{
MyMovableClass obj1(100), obj2(200); // constructor
MyMovableClass obj3(obj1); // copy constructor
MyMovableClass obj4 = obj1; // copy constructor
obj4 = obj2; // copy assignment operator
return 0;
}int main()
{
MyMovableClass obj1(100); // constructor
obj1 = MyMovableClass(200); // move assignment operator
MyMovableClass obj2 = MyMovableClass(300); // move constructor
return 0;
}Let us now consider a final example:
void useObject(MyMovableClass obj)
{
std::cout << "using object " << &obj << std::endl;
}
int main()
{
MyMovableClass obj1(100); // constructor
useObject(obj1);
return 0;
}In this case, an instance of MyMovableClass, obj1, is passed to a function useObject by value, thus making a copy of it.
Let us take an immediate look at the output of the program, before going into details:
(1)
CREATING instance of MyMovableClass at 0x7ffeefbff718 allocated with size = 400 bytes
(2)
COPYING content of instance 0x7ffeefbff718 to instance 0x7ffeefbff708
using object 0x7ffeefbff708
(3)
DELETING instance of MyMovableClass at 0x7ffeefbff708
(4)
CREATING instance of MyMovableClass at 0x7ffeefbff6d8 allocated with size = 800 bytes
(5)
MOVING (c'tor) instance 0x7ffeefbff6d8 to instance 0x7ffeefbff6e8
using object 0x7ffeefbff6e8
DELETING instance of MyMovableClass at 0x7ffeefbff6e8
DELETING instance of MyMovableClass at 0x7ffeefbff6d8
DELETING instance of MyMovableClass at 0x7ffeefbff718
First, we are creating an instance of MyMovableClass, obj1, by calling the constructor of the class (1).
Then, we are passing obj1 by-value to a function useObject, which causes a temporary object obj to be instantiated, which is a copy of obj1 (2) and is deleted immediately after the function scope is left (3).
Then, the function is called with a temporary instance of MyMovableClass as its argument, which creates a temporary instance of MyMovableClass as an rvalue (4). But instead of making a copy of it as before, the move constructor is used (5) to transfer ownership of that temporary object to the function scope, which saves us one expensive deep-copy.
There is one final aspect we need to look at: In some cases, it can make sense to treat lvalues like rvalues. At some point in your code, you might want to transfer ownership of a resource to another part of your program as it is not needed anymore in the current scope. But instead of copying it, you want to just move it as we have seen before. The "problem" with our implementation of MyMovableClass is that the call useObject(obj1) will trigger the copy constructor as we have seen in one of the last examples. But in order to move it, we would have to pretend to the compiler that obj1 was an rvalue instead of an lvalue so that we can make an efficient move operation instead of an expensive copy.
There is a solution to this problem in C++, which is std::move. This function accepts an lvalue argument and returns it as an rvalue without triggering copy construction. So by passing an object to std::move we can force the compiler to use move semantics, either in the form of move constructor or the move assignment operator:
int main()
{
MyMovableClass obj1(100); // constructor
useObject(std::move(obj1));
return 0;
}