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. Which one, I will answer in this post.

There 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++ has also a heap but prefers the stack. But these are by far not so only strategies for allocating memory. You can preallocate memory at the start time of the program as a fixed block or as a pool of memory blocks. This preallocated memory can afterward be used at the runtime of your program. But the key 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 to allocate and deallocate memory for its elements and to initialize and destruct them.

I overloaded in the last post operator new and delete. Therefore, it was possible to find memory leaks and get a 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 don't deallocate it. This is the job for 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. Sad to say, but 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 in 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!