new/delete

Dieser Artikel geht auf einige Don'ts ein. Dies sind vor allem die zwei wichtigsten Regeln des Artikels: Setze std::move nicht unüberlegt ein und wende kein Slicing an. Und los geht's.

Hier geht es direkt zum Artikel auf Heise Developer: https://www.heise.de/-3965137

Nachdem ich einige Artikel rund um das Speichermanagement in C++ geschrieben habe, bin ich sehr froh, Jonathan Müller für einen Gastartikel zu seiner Implementierung der memory Bibliothek in diesem Blog gewinnen zu können. Er wird die Konzepte rund um sein Design erklären. Jonathan ist als Experte zum Speichermangement in der C++-Community weltweit bekannt, sodass er in der 59 Episode Gast des cppcast war und seine Bibiothek den Zuhörern vorstellen konnte.

In C++ gibt es die Wahl zwischen verschiedenen Speicherstrategien. Neben der häufig verwendeten dynamischen Allokation und Allokation auf dem Stack, lässt sich der Speicher auch statisch zum Startzeitpunkt des Programms anfordern. Dies kann ein fester Block sein oder auch ein oder mehrere Memory Pools. Jeder dieser Strategien besitzt natürlich ihre Vor- und Nachteile. Genau diese Frage will dieser Artikel klären.

Es gibt viele Strategien, Speicher anzufordern. Programmiersprachen wie Python oder Java fordern ihren Speicher auf dem Heap zur Laufzeit des Programms an. C und C++ kennt natürlich auch den Heap, benutzt aber bevorzugt den Stack. Doch diese Strategie sind bei weitem noch nicht alle. Speicher lässt sich natürlich auch zur Startzeit des Programms als fester Block oder Pool von Blöcken vorallokieren und zur Laufzeit verwenden. Da stellt sich mir natürlich die Frage. Was sind die Vorteile dieser verschiedenen Strategien, Speicher anzufordern?

Was haben alle Container der Standard Template Library gemein? Sie besitzen einen Typ-Parameter Allocator, für den per Default std::allocator zum Einsatz kommt. Die Aufgabe des Speicherbeschaffers (allocator) besteht darin, den Lebenszyklus seiner Elemente zu verwalten. Das bedeutet, Speicher für die Elemente anzufordern und freizugeben und diese zu initialisieren und zu destruieren.

Im letzten Artikel habe ich operator new und delete überladen. Damit war es möglich, Speicherlecks zu erkennen und einen ersten Hinweis auf den Bösewicht zu erhalten. Meine Lösung besaß aber noch zwei größere Unschönheiten. Mit diesem Artikel werde ich diese beseitigen.

Häufig kommt es in C++ Applikationen vor, dass Speicher zwar angefordert aber nicht mehr freigegeben wird. Hier schlägt die Stunde von operator new und delete. Dank den beiden Operatoren ist es möglich, das Speichermanagement der Applikation explizit zu verwalten. 

Explizites Speichermanagement in C++ besitzt eine hohe Komplexität aber auch eine mindestens so große Funktionalität. Leider ist diese spezielle Domäne von C++ weitgehend unbekannt. So lassen sich mit ihr Objekte direkt in einem statischen Speicher, einem vorreserviertem Bereich oder auch einem Speicherpool erzeugen. Funktionalität, die für sicherheitskritische Applikationen insbesondere in der embedded Welt einen entscheidenden Mehrwert liefert. Doch vor der Kür steht die Pflicht. Daher werde ich in diesem Artikel einen Überblick geben, bevor ich in weiteren Artikeln auf die Details eingehen.