Welche Art von Zeiger verwende ich wann?

Die Entscheidung, welcher Smart Pointer verwendet werden soll, ist eine Frage von Eigentumsrecht. Wenn es um die Ressourcenverwaltung geht, ist Objekt A besitzt Objekt B, wenn es die Lebensdauer von Objekt B steuert. Beispielsweise gehören Mitgliedsvariablen ihren jeweiligen Objekten, da die Lebensdauer von Mitgliedsvariablen gebunden ist auf die Lebensdauer des Objekts. Sie wählen intelligente Zeiger basierend auf dem Besitz des Objekts.

Beachten Sie, dass das Eigentum an einem Softwaresystem vom Eigentum getrennt ist, wie wir es außerhalb von Software betrachten würden. Zum Beispiel könnte eine Person ihr Haus "besitzen", aber das bedeutet nicht unbedingt, dass ein Person - Objekt die Kontrolle über die Lebensdauer eines House - Objekts hat. Wenn Sie diese Konzepte der realen Welt mit Softwarekonzepten kombinieren, können Sie sich auf sichere Weise selbst in ein Loch programmieren.

Wenn Sie das alleinige Eigentum an dem Objekt haben, verwenden Sie std::unique_ptr<T>.

Wenn Sie das Eigentum an dem Objekt geteilt haben ...
- Wenn sich keine Zyklen im Besitz befinden, verwenden Sie std::shared_ptr<T>.
- Wenn es Zyklen gibt, definieren Sie eine "Richtung" und verwenden Sie std::shared_ptr<T> in eine Richtung und std::weak_ptr<T> in dem anderen.

Wenn das Objekt Ihnen gehört, Sie aber möglicherweise keinen Eigentümer haben, verwenden Sie normale Zeiger T* (z. B. übergeordnete Zeiger).

Wenn das Objekt Sie besitzt (oder anderweitig eine garantierte Existenz hat), verwenden Sie Referenzen T&.

Vorsichtsmaßnahme: Beachten Sie die Kosten für intelligente Zeiger. In speicher- oder leistungsbeschränkten Umgebungen kann es vorteilhaft sein, nur normale Zeiger mit einem manuelleren Schema für die Speicherverwaltung zu verwenden.

Die Kosten:

• Wenn Sie einen benutzerdefinierten Löscher haben (z. B. Sie verwenden Zuordnungspools), entsteht ein Overhead pro Zeiger, der durch manuelles Löschen leicht vermieden werden kann.
• std::shared_ptr hat den Overhead eines Referenzzählungsinkrements beim Kopieren, plus eines Dekrements beim Zerstören, gefolgt von einer 0-Zählungsprüfung mit Löschen des gehaltenen Objekts. Abhängig von der Implementierung kann dies Ihren Code aufblähen und Leistungsprobleme verursachen.
• Kompilierzeit. Wie bei allen Vorlagen wirken sich intelligente Zeiger negativ auf die Kompilierzeiten aus.

Beispiele:

struct BinaryTree
{
    Tree* m_parent;
    std::unique_ptr<BinaryTree> m_children[2]; // or use std::array...
};

Ein binärer Baum besitzt keinen übergeordneten Baum, aber die Existenz eines Baums impliziert die Existenz seines übergeordneten Baums (oder nullptr für root), sodass ein normaler Zeiger verwendet wird. Ein binärer Baum (mit Wertsemantik) hat das alleinige Eigentum seiner Kinder, das sind also std::unique_ptr.

struct ListNode
{
    std::shared_ptr<ListNode> m_next;
    std::weak_ptr<ListNode> m_prev;
};

Hier besitzt der Listenknoten seine nächste und vorherige Liste, also definieren wir eine Richtung und verwenden shared_ptr für next und weak_ptr for prev, um den Zyklus zu unterbrechen.

Verwenden Sie die ganze Zeit unique_ptr<T>, Es sei denn, Sie benötigen eine Referenzzählung. In diesem Fall verwenden Sie shared_ptr<T> (Und in sehr seltenen Fällen weak_ptr<T>, Um Referenzzyklen zu verhindern). In fast allen Fällen ist übertragbares Alleinstellungsmerkmal in Ordnung.

Rohe Zeiger: Nur gut, wenn Sie kovariante Renditen benötigen und keine eigenen Zeiger, die auftreten können. Ansonsten sind sie nicht besonders nützlich.

Array-Zeiger: unique_ptr Hat eine Spezialisierung für T[], Die automatisch delete[] Für das Ergebnis aufruft, sodass Sie beispielsweise sicher unique_ptr<int[]> p(new int[42]); ausführen können. shared_ptr Sie benötigen immer noch einen benutzerdefinierten Löscher, aber keinen speziellen gemeinsamen oder eindeutigen Array-Zeiger. Natürlich werden solche Dinge normalerweise sowieso am besten durch std::vector Ersetzt. Leider bietet shared_ptr Keine Array-Zugriffsfunktion, sodass Sie get() immer noch manuell aufrufen müssen, aber unique_ptr<T[]> Bietet operator[] Anstelle von operator* Und operator->. In jedem Fall muss man sich grenzenlos kontrollieren. Dies macht shared_ptr Etwas weniger benutzerfreundlich, obwohl der allgemeine Vorteil und die fehlende Abhängigkeit von Boosts unique_ptr Und shared_ptr Erneut zu den Gewinnern machen.

Bereichsspezifische Zeiger: Durch unique_ptr Irrelevant gemacht, genau wie auto_ptr.

Da ist wirklich nichts mehr dran. In C++ 03 ohne Verschiebungssemantik war diese Situation sehr kompliziert, aber in C++ 11 ist der Rat sehr einfach.

Es gibt noch Verwendungen für andere intelligente Zeiger wie intrusive_ptr Oder interprocess_ptr. Sie sind jedoch sehr Nischen und im allgemeinen Fall völlig unnötig.

Fälle, in denen unique_ptr Verwendet werden soll:

• Fabrik methoden
• Mitglieder, die Zeiger sind (Pickel enthalten)
• Speichern von Zeigern in STL-Containern (um Bewegungen zu vermeiden)
• Verwendung großer lokaler dynamischer Objekte

Fälle, in denen shared_ptr Verwendet werden soll:

• Objekte über Threads hinweg teilen
• Objekte im Allgemeinen teilen

Fälle, in denen weak_ptr Verwendet werden soll:

• Große Karte, die als allgemeine Referenz dient (z. B. eine Karte aller offenen Sockets)

Fühlen Sie sich frei, um mehr zu bearbeiten und hinzuzufügen