Introduction

Ooops. Yet another article on smart pointers of C++11. Nowadays I hear a lot of people talking about the new C++ standard which is nothing but C++0x/C++11.
I went through some of the language features of C++11 and it's really an amazing work. I'll focus only on the smart pointers section of C++11.

Background

What are the issues with normal/raw/naked pointers?

Let's go one by one.

People refrain from using pointers as they give a lot of issues if not handled properly. That's why newbie programmers dislike pointers.
Many issues are involved with pointers like ensuring the lifetime of objects referred
to by pointers, dangling references, and memory leaks.

Dangling reference is caused if a memory block is pointed by more than one pointer variable and if one of the pointers is released without letting know the other pointer. As all of you know, memory leaks occur when a block of memory is fetched from the heap and is not released back.

People say, I write clean and error proof code, why should I use smart pointers? And a programmer asked me, "Hey,
here is my code. I fetched the memory from the heap,
manipulated it, and after that I released it properly. What is the need of a smart pointer? "

The above code works fine and memory is released properly under ideal circumstances. But think of the practical environment of code execution. The instructions between
memory allocation and releasing can do nasty things like accessing an invalid memory location, dividing by zero, or say another programmer pitching into your program
to fix a bug and adding a premature return statement based on some condition.

In all the above cases, you will never reach the point where the memory is released.
This is because the first two cases throw an exception whereas the third one is a
premature return.
So the memory gets leaked while the program is running.

The one stop solution for all of the above issues is Smart Pointers [if they are really smart enough].

What is a smart pointer?

Smart pointer is a RAII modeled class to manage dynamically allocated memory. It provides all the interfaces provided by normal pointers with
a few exceptions.
During construction, it owns the memory and releases the same when it goes out of scope. In this way, the programmer is free about managing dynamically allocated memory.

C++98 has introduced the first of its kind called auto_ptr.

auto_ptr

Let's see the use of auto_ptr and how smart it is to resolve the above issues.

The above code is smart to release the memory associated with it. What we did is, we fetched a memory block to hold an object of type
Test and associated it with auto_ptr p. So when p goes out of scope, the associated memory block is also released.

In the above case, an exception is thrown but still the pointer is released properly. This is because of stack unwinding which happens when an exception is thrown. As all local objects belonging to the
try block are destroyed, p goes out of scope and it releases the associated memory.

Issue 1: So far
auto_ptr is smart. But it has more fundamental flaws over its smartness.
auto_ptr transfers the ownership when it is assigned to another
auto_ptr. This is really an issue while passing the auto_ptr between the functions. Say, I have an
auto_ptr in Foo( ) and this pointer is passed another function say
Fun( ) from Foo. Now once Fun( ) completes its execution, the ownership is not returned back to
Foo.

The above code causes a program crash because of the weird behavior of
auto_ptr. What happens is that, p owns a memory block and when
Fun is called, p transfers the ownership of its associated memory block
to the auto_ptrp1 which is the copy of p. Now
p1 owns the memory block which was previously owned by p. So far it
is fine. Now fun has completed its execution, and p1 goes out of scope and the memory blocked is released. How about
p? p does not own anything, that is why it causes a crash when the next line is executed which accesses
p thinking that it owns some resource.

Issue 2: Yet another flaw.
auto_ptr cannot be used with an array of objects. I mean it cannot be used with the operator new[].

The above code gives a runtime error. This is because when auto_ptr goes out of scope,
delete is called on the associated memory block. This is fine if
auto_ptr owns only a single object. But in the above code, we have created
an array of objects on the heap which should be destroyed using delete[ ] and not
delete.

Issue 3:auto_ptr cannot be used with standard containers like vector, list, map,
etc.

As auto_ptr is more error prone and it will be deprecated, C++ 11 has come with a new set of smart pointers, each has its own purpose.

shared_ptr

unique_ptr

weak_ptr

shared_ptr

OK,
get ready to enjoy the real smartness. The first of its kind is shared_ptr which has the notion called shared ownership. The goal of
shared_ptr is very simple: Multiple shared pointers can refer to a single object and when the last shared pointer goes out of scope,
memory is released automatically.

Creation:

void main( )
{
shared_ptr<int> sptr1( newint );
}

Make use of the make_shared macro which expedites the
creation process. As shared_ptr allocates memory internally, to hold the reference count,
make_shared( ) is implemented in a way to do this job effectively.

void main( )
{
shared_ptr<int> sptr1 = make_shared<int>(100);
}

The above code creates a shared_ptr which points to a memory block to hold an integer with value 100 and reference count 1. If another shared pointer is created out of
sptr1, the reference count goes up to 2. This count is known as strong reference. Apart from this, the shared pointer has another reference count known as weak reference, which will
be explained while visiting weak pointers.

You can find out the number of
shared_ptrs referring to the resource by just getting the reference
count by calling use_count( ). And while debugging, you can get it by watching the
stong_ref of the shared_ptr.

Destruction:

shared_ptr releases the
associated resource by calling delete by default. If the user needs a different destruction policy, he/she is free to specify the same while constructing the
shared_ptr. The following code is a source of trouble due to the default destruction policy:

Because shared_ptr owns an array of objects, it calls delete when
it goes out of scope. Actually, delete[ ] should have been called to destroy the array.
The user can specify the custom deallocator by a callable object, i.e., a function,
lambda expression, function object.

The above piece of code is going to cause an error because two shared_ptrs from different groups share a single resource. The below table gives you
a picture of the root cause.

To avoid this, better not create the shared pointers from a naked pointer.

There is another issue involved with creating a shared pointer from a naked pointer. In the above code, consider that only one shared pointer is created using
p and the code works fine. Consider by mistake if a programmer deletes the naked pointer
p before the scope of the shared pointer ends. Oooppss!!! Yet another crash..

Cyclic Reference: Resources are not released properly if a cyclic reference of shared pointers are involved. Consider the following piece of code.

The above code has cyclic reference. I mean class A holds a shared pointer to B and class B holds
a shared pointer to A. In this case, the resource associated
with both sptrA and sptrB are not released. Refer to the below table.

Reference counts for both sptrA and sptrB go down to 1 when they go out of scope and hence the resources are not released!!!!!

To resolve the cyclic reference, C++ provides another smart pointer class called
weak_ptr.

Weak_Ptr

A weak pointer provides sharing semantics and not owning semantics. This means
a weak pointer can share a resource held by a shared_ptr.
So to create a weak pointer, some body should already own the resource which is nothing but a shared pointer.

A weak pointer does not allow normal interfaces supported by a pointer, like calling
*, ->. Because it is not the owner of the resource and hence it does not give
any chance for the programmer to mishandle it. Then how do we make use of a weak pointer?

The answer is to create a
shared_ptr out of a weak _ptr and use it.
Because this makes sure that the resource won't be destroyed while using by incrementing
the strong reference count. As the reference count is incremented,
it is sure that the count will be at least 1 till you complete using the shared_ptr created out of the
weak_ptr. Otherwise what may happen
is while using the weak_ptr, the resource held by the shared_ptr goes out of scope and the memory is released which creates chaos.

Creation

A weak pointer constructor takes a shared pointer as one of its parameters. Creating a weak pointer out of
a shared pointer increases the weak reference counter
of the shared pointer. This means that the shared pointer shares it resource with another pointer. But this counter is not considered to release the resource when
the shared pointer goes out of scope. I mean if the strong reference of the shared pointer goes to 0, then the resource is released irrespective of the weak reference value.

Unique_ptr

This is almost a kind of replacement to the error prone auto_ptr.
unique_ptr follows the exclusive ownership semantics, i.e., at any point of time, the resource is owned
by only one unique_ptr. When auto_ptr goes out of scope, the resource is released. If the resource is overwritten by some other resource, the previously owned resource
is released. So it guarantees that the associated resource is released always.

Creation

unique_ptr is created in the same way as shared_ptr except it has an additional facility for
an array of objects.

unique_ptr<int> uptr( newint );

The unique_ptr class provides the specialization to create an array of objects which calls
delete[ ] instead of delete when the pointer goes out of scope.
The array of objects can be specified as a part of the template parameter while creating the
unique_ptr. In this way, the programmer does not have to provide a custom deallocator,
as unique_ptr does it.

unique_ptr<int[ ]> uptr( newint[5] );

Ownership of the resource can be transferred from one unique_ptr to another by assigning it.

Keep in mind that unique_ptr does not provide you copy semantics [copy assignment and copy
construction is not possible] but move semantics.

In the above case, if upt3 and uptr5 owns some resource already, then it will be destroyed properly before owning a new resource.

Interface

The interface that unique_ptr provides is very similar to the ordinary pointer but no pointer arithmetic is allowed.

unique_ptr provides a function called release which yields the ownership.
The difference between release( ) and reset( ), is
release just yields the ownership
and does not destroy the resource whereas reset destroys the resource.

Which one to use?

It purely depends upon how you want to own a resource. If shared ownership is needed then go for
shared_ptr, otherwise unique_ptr.

Apart from that, shared_ptr is a bit heavier than unique_ptr because internally it allocates memory to do
a lot of book keeping like strong reference,
weak reference, etc. But unique_ptr does not need these counters as it is the only owner for the resource.

Using the code

I have attached the worked out code to explain the details of each pointer. I have added enough comments to each instruction. Ping me back if you find any problems with the code.
The weak pointer example demonstrates the problems with shared pointers in the case of cyclic reference and how the weak pointer resolves it.

History

This is the first version of the article. I'll keep you updated based on feedback and comments.

Hi Syed,
Thanks for sharing such a nice and well conclusive information about the smart pointers. Specially issues mentioned for smart pointers are really helpful for handling the smart pointers smartly.

A google search shows that the reference counts are handled atomically, but what about the conversion from a weak_ptr to a shared_ptr?

If for example I have a weak_ptr to an object, and make a shared_ptr to it to use it in one thread 'meanwhile' in another thread the only other strong reference to the object goes out of scope, is there likely to be a race condition on the shared_ptr in this thread?

Great overview of the standard smart pointers. Using these type of classes does away with memory and resource leaks if used correctly (something not even Garbage Collection can do). Great introduction, keep up the good work.

I sometimes wonder if there is something that turn C++ programmers into grumpy old men, as the way we sometimes treat those who actually try to make a positive contribution leaves a bit to be desired ...

Just to remind you a Danny Kalev's interview: C# and likes are good at making programmers more productive; C and C++ are the best at speed of execution. And now, with big data, speed is prevailing. Besides, lot of embedded programming is in C and sometimes in C++, not in C#. Think about microwave ovens.