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. 

A std::unique_ptr manages automatically and exclusively the lifetime of its resource according to the RAII idiom. std::unique_ptr should be your first choice because it does its work without memory or performance overhead.

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 few reasons in modern C++ justifying the memory management with new and delete.

The careful handling of resources - may it be for example memory, files or sockets - is a key concern of programming in C++. This holds in particular true for the embedded programming that is often characterized by limited resources. Therefore, I will write a few posts about this challenging and versatile topic.

Plain Old Data (POD) obeys the C standard layout. Therefore, you directly can apply the fast C functions memcopy, memmove, memset, or memcmp.

The hash function maps a potential infinite number of keys on a finite number of buckets. What is the strategy of the C++ runtime and how can you tailor it to your needs, that is what this article is all about.

The reason for the constant access time (best cast) of the unordered associative containers are the hash functions. As ever, C++ offers a lot of ways to adjust the behaviour of the hash functions. On one hand, C++ has a lot of different hash functions; on the other hand, you can define your own hash function. You can even adjust the number of buckets.

Before I take a deeper look insight the interface of the hash tables - officially called unordered associative containers - I will at first compare the performance of the associative containers. The best candidates are std::unordered_map and the ordered pendant std::map because both are used most frequently.