After I have written a few posts about memory management in C++, I'm very glad to present Jonathan Müller, which will write a guest post about his implementation of the memory library. He will explain to us his concepts about his design. Jonathan is known as an expert in memory management in the C++ community. In the  59 episodes, he presented his ideas to a worldwide audience.

In C++ you have the choice between various memory allocation strategies. In addition to the frequently used dynamic memory allocation, you have the stack allocation. But you can preallocate the memory at the start time of your program. This can be a fixed-sized block or one or more memory pools. Each of these strategies has its pros and cons. One, I will answer in this post.

There are a lot of different strategies for allocating memory. Programming languages like Python or Java request their memory from the heap at runtime. Of course, C or C++ also has a heap but prefers the stack. But these are by far not so only strategies for allocating memory. You can preallocate memory at the program's start time as a fixed block or a pool of memory blocks. This preallocated memory can afterward be used at the runtime of your program. But the critical question is: What are the pros and cons of the various strategies to allocate memory?

What is common between all containers of the Standard Template Library? They have a type parameter Allocator that is by default std::allocator. The job of the allocator is to manage the lifetime of its elements. That means allocating and deallocating memory for its elements and initializing and destroying them.

I overloaded in the last post operator new and delete. Therefore, finding memory leaks and getting the first hint of the bad guys. My solution had two not-so-nice properties. With this post, I will overcome them.

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!

Today, we solve " ... a herefore unsolved problem in C++" (Bjarne Stroustrup). To make the long story short, I will write about perfect forwarding.

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!