Speicher

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.

Nachdem ich im letzten Artikel das große Bild zu std::shared_ptr beschrieben habe, komme ich heute zu zwei besonderen Aspekten der Smart Pointer. Zum einen zeige ich mit std::shared_from_this, wie sich ein std::shared_ptr von einem Objekt erzeugen lässt, zum anderen beschäftigt mich die Frage: Soll ein std::shared_ptr per Copy oder per Referenz übergeben werden. Insbesondere der zweite Punkt besitzt einiges an Überraschungspotential.

std::shared_ptr teilen sich eine gemeinsame Ressource. Dabei zählt der gemeinsame Referenzzähler mit, wie viele Besitzer die Ressource hat. Wird der Smart Pointer std::shared_ptr kopiert, erhöht sich automatisch der Referenzzähler. Beim Löschen eines std::shared_prt wird sein Referenzzähler hingegen automatisch erniedrigt. Erreicht der Referenzzähler den Wert 0, wird die Ressource freigegeben.