shared_ptr

The Covariant Return Type of a member function allows an overriding member function to return a narrower type. This is particularly useful when you implement the Prototype Pattern.

Concurrency provides many ways to shoot yourself in the foot. The rules for today help you to know these dangers and to overcome them.

std::unique_ptr models the concept of exclusive ownership, std::shared_ptr the concept of shared ownership. If I stick to this picture then std::weak_ptr models the concept of temporary ownership because it borrows the resource from a std::shared_ptr. There is one dominant reason for having a std::weak_ptr in C++: breaking of cyclic references of std::shared_ptr's.

After I draw the big picture of a std::shared_ptr's in the last post, I want to present two special aspects of this smart pointer in this post. First, I show with std::shared_from_this how to create a std::shared_ptr from an object; second, I'm interested in the question to the answer: Should a function take a std::shared_ptr by copy or by reference? The numbers are quite interesting.

std::shared_ptr's share the resource. The shared reference counter counts the number of owners. Copying a std::shared_ptr increases the reference count by one. Destroying a std::shared_ptr decreases the reference count by one. If the reference count becomes zero, the resource will automatically be released. 

C++11 offers four different smart pointers. On two of them, I will have a closer look in this post regarding memory and performance overhead. My first candidate std::unique_ptr takes exclusively care of the lifetime of one resource; std::shared_ptr shares the ownership of a resource with other std::shared_ptr's. I will state the result of my tests before I show you the raw numbers: There are only a few reasons in modern C++ justifying the memory management with new and delete.