Chapter 33: Smart Pointers

conveys the ownership semantics of the return: the caller owns the resulting unique_ptr and is responsible for it.

std::unique_ptr<int> foo()

{

std::unique_ptr<int> ptr = std::make_unique<int>(59); return ptr;

}

std::unique_ptr<int> ptr = foo();

Compare this to:

int* foo_cpp03();

int* p = foo_cpp03(); // do I own p? do I have to delete it at some point? // it's not readily apparent what the answer is.

Version < C++14

The class template make_unique is provided since C++14. It's easy to add it manually to C++11 code:

template<typename T, typename... Args>

typename std::enable_if<!std::is_array<T>::value, std::unique_ptr<T>>::type make_unique(Args&&... args)

{ return std::unique_ptr<T>(new T(std::forward<Args>(args)...)); }

// Use make_unique for arrays template<typename T>

typename std::enable_if<std::is_array<T>::value, std::unique_ptr<T>>::type make_unique(size_t n)

{ return std::unique_ptr<T>(new typename std::remove_extent<T>::type[n]()); }

Version ≥ C++11

Unlike the dumb smart pointer (std::auto_ptr), unique_ptr can also be instantiated with vector allocation (not std::vector). Earlier examples were for scalar allocations. For example to have a dynamically allocated integer array for 10 elements, you would specify int[] as the template type (and not just int):

std::unique_ptr<int[]> arr_ptr = std::make_unique<int[]>(10);

Which can be simplified with:

auto arr_ptr = std::make_unique<int[]>(10);

Now, you use arr_ptr as if it is an array: arr_ptr[2] = 10; // Modify third element

You need not to worry about de-allocation. This template specialized version calls constructors and destructors appropriately. Using vectored version of unique_ptr or a vector itself - is a personal choice.

In versions prior to C++11, std::auto_ptr was available. Unlike unique_ptr it is allowed to copy auto_ptrs, upon which the source ptr will lose the ownership of the contained pointer and the target receives it.

Section 33.2: Sharing ownership (std::shared_ptr)

The class template std::shared_ptr defines a shared pointer that is able to share ownership of an object with

other shared pointers. This contrasts to std::unique_ptr which represents exclusive ownership.

The sharing behavior is implemented through a technique known as reference counting, where the number of shared pointers that point to the object is stored alongside it. When this count reaches zero, either through the destruction or reassignment of the last std::shared_ptr instance, the object is automatically destroyed.

// Creation: 'firstShared' is a shared pointer for a new instance of 'Foo' std::shared_ptr<Foo> firstShared = std::make_shared<Foo>(/*args*/);

To create multiple smart pointers that share the same object, we need to create another shared_ptr that aliases the first shared pointer. Here are 2 ways of doing it:

Either of the above ways makes secondShared a shared pointer that shares ownership of our instance of Foo with firstShared.

The smart pointer works just like a raw pointer. This means, you can use * to dereference them. The regular -> operator works as well:

secondShared->test(); // Calls Foo::test()

Finally, when the last aliased shared_ptr goes out of scope, the destructor of our Foo instance is called.

Warning: Constructing a shared_ptr might throw a bad_alloc exception when extra data for shared ownership semantics needs to be allocated. If the constructor is passed a regular pointer it assumes to own the object pointed to and calls the deleter if an exception is thrown. This means shared_ptr<T>(new T(args)) will not leak a T object if allocation of shared_ptr<T> fails. However, it is advisable to use make_shared<T>(args) or allocate_shared<T>(alloc, args), which enable the implementation to optimize the memory allocation.

Allocating Arrays([]) using shared_ptr

Version ≥ C++11 Version < C++17

Unfortunately, there is no direct way to allocate Arrays using make_shared<>.

It is possible to create arrays for shared_ptr<> using new and std::default_delete.

For example, to allocate an array of 10 integers, we can write the code as

shared_ptr<int> sh(new int[10], std::default_delete<int[]>());

Specifying std::default_delete is mandatory here to make sure that the allocated memory is correctly cleaned up using delete[].

If we know the size at compile time, we can do it this way:

template<class Arr>

struct shared_array_maker {}; template<class T, std::size_t N> struct shared_array_maker<T[N]> {

std::shared_ptr<T> operator()const{

auto r = std::make_shared<std::array<T,N>>(); if (!r) return {};

return {r.data(), r};

}

};

template<class Arr> auto make_shared_array()

-> decltype( shared_array_maker<Arr>{}() ) { return shared_array_maker<Arr>{}(); }

then make_shared_array<int[10]> returns a shared_ptr<int> pointing to 10 ints all default constructed.

Version ≥ C++17

With C++17, shared_ptr gained special support for array types. It is no longer necessary to specify the array-deleter explicitly, and the shared pointer can be dereferenced using the [] array index operator:

std::shared_ptr<int[]> sh(new int[10]); sh[0] = 42;

Shared pointers can point to a sub-object of the object it owns:

struct Foo { int x; };

std::shared_ptr<Foo> p1 = std::make_shared<Foo>(); std::shared_ptr<int> p2(p1, &p1->x);

Both p2 and p1 own the object of type Foo, but p2 points to its int member x. This means that if p1 goes out of scope or is reassigned, the underlying Foo object will still be alive, ensuring that p2 does not dangle.

Important: A shared_ptr only knows about itself and all other shared_ptr that were created with the alias constructor. It does not know about any other pointers, including all other shared_ptrs created with a reference to the same Foo instance:

Foo *foo = new Foo; std::shared_ptr<Foo> shared1(foo);

std::shared_ptr<Foo> shared2(foo); // don't do this

shared1.reset(); // this will delete foo, since shared1 // was the only shared_ptr that owned it

shared2->test(); // UNDEFINED BEHAVIOR: shared2's foo has been // deleted already!!

Ownership Transfer of shared_ptr

By default, shared_ptr increments the reference count and doesn't transfer the ownership. However, it can be made to transfer the ownership using std::move:

shared_ptr<int> up = make_shared<int>();

//Transferring the ownership shared_ptr<int> up2 = move(up);

//At this point, the reference count of up = 0 and the

//ownership of the pointer is solely with up2 with reference count = 1

Section 33.3: Sharing with temporary ownership

(std::weak_ptr)

Instances of std::weak_ptr can point to objects owned by instances of std::shared_ptr while only becoming temporary owners themselves. This means that weak pointers do not alter the object's reference count and therefore do not prevent an object's deletion if all of the object's shared pointers are reassigned or destroyed.

In the following example instances of std::weak_ptr are used so that the destruction of a tree object is not inhibited:

#include <memory> #include <vector>

struct TreeNode { std::weak_ptr<TreeNode> parent;

std::vector< std::shared_ptr<TreeNode> > children;

};

int main() {

//Create a TreeNode to serve as the root/parent. std::shared_ptr<TreeNode> root(new TreeNode);

//Give the parent 100 child nodes.

for (size_t i = 0; i < 100; ++i) { std::shared_ptr<TreeNode> child(new TreeNode); root->children.push_back(child); child->parent = root;

}

//Reset the root shared pointer, destroying the root object, and

//subsequently its child nodes.

root.reset();

}

As child nodes are added to the root node's children, their std::weak_ptr member parent is set to the root node. The member parent is declared as a weak pointer as opposed to a shared pointer such that the root node's reference count is not incremented. When the root node is reset at the end of main(), the root is destroyed. Since the only remaining std::shared_ptr references to the child nodes were contained in the root's collection children, all child nodes are subsequently destroyed as well.

Due to control block implementation details, shared_ptr allocated memory may not be released until shared_ptr reference counter and weak_ptr reference counter both reach zero.

#include <memory> int main()

{

{

std::weak_ptr<int> wk;

{

//std::make_shared is optimized by allocating only once

//while std::shared_ptr<int>(new int(42)) allocates twice.

//Drawback of std::make_shared is that control block is tied to our integer std::shared_ptr<int> sh = std::make_shared<int>(42);

wk = sh;

//sh memory should be released at this point...

}

// ... but wk is still alive and needs access to control block

}

// now memory is released (sh and wk)