proggen.org

Hi, ich habe eine Frage zu Owning- und Non-Owning Pointern, d.h. Objekt X besitzt ein Objekt Y und ein Objekt Z soll Objekt Y kennen, aber nicht besitzen.

Soweit ich den aktuellen Standard überblicke, verwende ich std::shared_ptr für shared ownership, d.h. wenn ich mehrere Besitzer habe. Entsprechend kann für die non-owning Pointer dann std::weak_ptr verwenden. Soweit so gut.

Aber was, wenn ich im Design explizit genau einen Besitzer habe? Dann sollte ich ja zu std::unique_ptr tendieren (kein Overhead im vgl. zum shared Pointer). Nur fehlt hier das weak-Pointer-Äquivalent. Meine intuitive Herangehensweise wäre: Raw Pointer und darauf achten, dass ich diesen auf nullptr resette, sobald der unique Pointer "stirbt".

Im Grunde ist das ja keine Verletzung von RAII.. es gibt immer wieder die Gegner von raw Pointern, die seit C++11 enorm zugenommen zu haben scheinen. Aber deswegen "blind" shared und weak Pointer zu verwenden, erscheint mir falsch, da mir dann die explizit-genau-ein-Besitzer-Semantik verloren geht.

Habt ihr da eine Idee?

LG Glocke

Wenn etwas unique ist, dann bedeutet das doch eben auch, dass es keine anderen Pointer geben darf!?
Entsprechend widerspricht ein weak_ptr auf einen unique_ptr doch der Idee des Unique-Pointers?

Aber was, wenn ich im Design explizit genau einen Besitzer habe?

Du kannst einen shared_ptr nutzen und nur weak_ptr herausgeben, oder du nutzt einen unique_ptr und gibst direkt Referenzen auf das Objekt aus anstatt eines unique_ptrs.

Xin hat geschrieben:Wenn etwas unique ist, dann bedeutet das doch eben auch, dass es keine anderen Pointer geben darf!?
Entsprechend widerspricht ein weak_ptr auf einen unique_ptr doch der Idee des Unique-Pointers?

Naja:

• Unique Pointer heißt unique Ownership, d.h. genau ein Besitzer.
• Shared Pointer heißt shared Ownership, d.h. 1..n Besitzer. Jedes Teilen bedeutet Teilen im Sinne der Besitzerschaft.
• Weak Pointer heißt (entsprechend std), dass ein Shared Pointer als non-owning Pointer geteilt wird.

Von daher widerspricht das der unique Definition nicht: Der Besitzer ist unique.

cloidnerux hat geschrieben:Du kannst einen shared_ptr nutzen und nur weak_ptr herausgeben

Naja das möchte ich eben nicht - ich lege Wert auf das unique - immerhin habe ich immer nur einen Besitzer.

cloidnerux hat geschrieben:oder du nutzt einen unique_ptr und gibst direkt Referenzen auf das Objekt aus anstatt eines unique_ptrs.

Ja genau. Das funktioniert solange ein "Customizer" (der den Pointer non-owning haben soll, d.h. den Pointer "kennt") von Erzeugung bis Zerstörung (seiner selbst) immer genau einen unique_ptr referenziert. Sobald das zur Laufzeit variieren soll, kann ich schon keine Referenz mehr nehmen. Da würde ich dann halt den raw Pointer verteilen. Da der als non-owning verwendet wird, wird den auch keiner deleten.

Hi,

gemäß der Guideline von Herb Sutter: http://herbsutter.com/elements-of-modern-c-style/

Smart pointers: No delete
Always use the standard smart pointers, and non-owning raw pointers. Never use owning raw pointers and delete, except in rare cases when implementing your own low-level data structure (and even then keep that well encapsulated inside a class boundary).

wäre die Verwendung von non-owning raw pointern als "Beobachter" eines unique pointers ratsam. Da mir dann aber immer noch das resetten (auf nullptr) - wenn der unique pointer die scope verlässt - fehlen. Da das Verwenden eines customized deleters nicht für move gilt, hilft mir das schonmal nicht. Als Resultat habe ich mir selber einen sole_ptr (Ableitung von unique_ptr) als unique owning pointer - und einen dynamic_ptr als non-owning pointer, der einen sole_ptr beobachtet, geschrieben:

Implementierung: https://github.com/cgloeckner/std_ext/b ... le_ptr.hpp
Testcases und Beispielcode:
https://github.com/cgloeckner/std_ext/b ... r_test.cpp

Was haltet ihr davon?

LG Glocke