Speicher

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.

C++ ist eine so altmodische Programmiersprache. Sie unterstützt kein Garbage Collection. Kein Garbage Collection? Stimmt! Altmodisch? Stimmt nicht!

std::array verbindet das Beste aus zwei Welten. Zum einen besitzt es die Größe und Effizienz eines C-Arrays, zum anderen bietet es das Interface eines std::vector an.

Einer der großen Vorteile des C++-Strings gegenüber dem C-String, bzw. dem std:::vector gegenüber dem C-Array ist es, dass diese C++ Datenstrukturen automatisch ihren Speicher verwalten. Dies trifft natürlich neben dem std::string auf alle Container der Standard Template Library zu. Diese automatische Speicherverwaltung will ich mir in diesem Artikel für den std::vector und den std::string genauer anschauen.

std::unique_ptr verkörpert das Konzept des exklusiven, std::shared_ptr des geteilten Besitzes. Bleibe ich in diesem Bild, dann verkörpert der std::weak_ptr das Konzept des zeitlich eingeschränkten Besitzes, den er leiht sich die Ressource von einem std::shared_ptr aus. Der std::weak_ptr besitzt insbesondere eine Existenzberechtigung: Zyklische Referenzen von std::shared_ptr zu brechen.