Memory

It happens quite too often that a C++ application allocates memory but doesn't deallocate it. This is the job of the operator to new and delete. Thanks to them both, you can explicitly manage the memory management of an application.

Explicit memory management has in C++ a high complexity but also provides great functionality. Sadly, this special domain is not so known in C++. For example, you can directly create objects in static memory, in a reserved area, or even a memory pool. That is functionality, which is often key in safety-critical applications in the embedded world. Before the harvest is the work, therefore, I will give in this post an overview, before I dive deeper into the details.

C++ is old-fashioned. C++ has no garbage collection. No garbage collection? Right! Old fashioned? Wrong!

I will talk about two nice properties of the move semantic in this post that is not so often mentioned. Containers of the standard template library (STL) can have non-copyable elements. The copy semantic is the fallback for the move semantic. Irritated? I hope so!

A lot was written about the advantages of move semantics to copy semantics. Instead of an expensive copy operation, you can use a cheap move operation. But what does that mean? In this post, I will compare the copy and move semantics performance for the Standard Template Library (STL) containers. 

std::array combines the best of two worlds. On the one hand, std::array has the size and efficiency of a C array; on the other hand, std::array has the interface of a std::vector. 

One of the significant advantages of a C++ string to a C string and of a std::vector to a C array is that both C++ containers automatically manage their memory. Of course, that holds for all further containers of the Standard Template Library. In this post, I will look closer at the automatic memory management of std::vector and std::string.

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 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.