Anwendungszweck von shared_ptr<T>?

[shared_ptr]

Gibt es einen sinnvollen Anwendungszweck von shared_ptr<T>? Also einer, der nicht auf schlechtes Design zurückzuführen ist.

Objekte mit unique_ptr<T> zu halten macht Sinn.
shared_ptr<const T> als Copy-Optimierung macht auch Sinn (also shared_ptr mit immutable Objekten).

Aber shared_ptr<T>?

[knivil]

Ja.

[shared_ptr]

z.B.?

[Sone]

shared_ptr schrieb:

z.B.?

shared ownership.

[shared_ptr]

Sone schrieb:

shared_ptr schrieb:

z.B.?

shared ownership.

Das ist ein Prinzip, kein Anwendungszweck.

[knivil]

Nun, mein Beispiel, wo ich es gebraucht habe, ist zu lang, um hier dargestellt zu werden.

[shared ownerboat]

shared_ptr schrieb:

Das ist ein Prinzip, kein Anwendungszweck.

Du wirst von zwei Kerlen geliebt. Es ist nun nicht ganz klar, wem du gehörst. Also shared ownership. Ok, einer stirbt, also bleibt der andere. Jetzt gehörst du ihm.

Klar?

[camper]

shared ownerboat schrieb:

shared_ptr schrieb:

Das ist ein Prinzip, kein Anwendungszweck.

Du wirst von zwei Kerlen geliebt. Es ist nun nicht ganz klar, wem du gehörst. Also shared ownership. Ok, einer stirbt, also bleibt der andere. Jetzt gehörst du ihm.

Klar?

Und wenn der auch stirbt, begeht man Suizid?

[Sone]

camper schrieb:

Und wenn der auch stirbt, begeht man Suizid?

Natürlich! Hätte Lotte nicht Suizid begangen, wenn sowohl Albert als auch Werther sich umgebracht hätten? (Ich bin ownerboat, ich konnte nicht widerstehen)

Nein, aber mal ernsthaft, das ist natürlich ein schlechtes (wenn nicht falsches) Beispiel.

knivil schrieb:

Nun, mein Beispiel, wo ich es gebraucht habe, ist zu lang, um hier dargestellt zu werden.

Schon nur die Idee? Es muss ja kein Code sein, nur eine Erklärung des Designs.

[Sone]

Vielleicht entspricht shared ownership ja nichts reellem. Sondern es ist ein hilfreiches Prinzip, dass bestimmte Designs einfacher [zu implementieren] macht.

[volkard]

shared_ptr schrieb:

Gibt es einen sinnvollen Anwendungszweck von shared_ptr<T>? Also einer, der nicht auf schlechtes Design zurückzuführen ist.

Ein Sender schickt Jobs an mehrer Empfänger und alle können damit was tun. Nur interessiert es den Sender nicht, wann und ob sie jeweils ihren Job verarbeiten, er muss sie nur benachrichtigt haben. Der letze, der den Job verarbeitet oder ignoriert, macht das List aus. Zum Beispiel in einem Netzwerksimulator die Pakete, die über den Bus gehen.

[Sone]

Zwei Fragen:

• Sind die Jobs so teuer zu kopieren?
• Wieso besitzen die Empfänger die Jobs?

Edit:

Zum Beispiel in einem Netzwerksimulator die Pakete, die über den Bus gehen.

Das hast du aber hinterhereditiert.

[shared_ptr]

volkard schrieb:

shared_ptr schrieb:

Gibt es einen sinnvollen Anwendungszweck von shared_ptr<T>? Also einer, der nicht auf schlechtes Design zurückzuführen ist.

Ein Sender schickt Jobs an mehrer Empfänger und alle können damit was tun. Nur interessiert es den Sender nicht, wann und ob sie jeweils ihren Job verarbeiten, er muss sie nur benachrichtigt haben. Der letze, der den Job verarbeitet oder ignoriert, macht das List aus. Zum Beispiel in einem Netzwerksimulator die Pakete, die über den Bus gehen.

Das wäre dann shared_ptr mit immutable-Objekten oder nicht? Das ist nämlich ok.

Sone schrieb:

Sondern es ist ein hilfreiches Prinzip, dass bestimmte Designs einfacher [zu implementieren] macht.

Im Gegenteil, shared_ptr ist die Hölle! Du kannst überhaupt gar nichts über den Zustand des Objekts sagen, da er sich jederzeit ändern könnte.

[volkard]

Sone schrieb:

Zwei Fragen:

• Sind die Jobs so teuer zu kopieren?
• Wieso besitzen die Empfänger die Jobs?

Edit:

Zum Beispiel in einem Netzwerksimulator die Pakete, die über den Bus gehen.

Das hast du aber hinterhereditiert.

Jo, hab konkretisiert.
Die Jobs sind teuere zu kopieren als der shard_ptr-Trick. Sie besitzen, weil der Sender sie echt loslassen will.
Also eigentlich nur ein Implementierungsdetail, um Speed zu machen. Da habe ich es benutzt.

Wo braucht man sie wirklich?

[Sone]

Soll eigentlich ein shared_ptr durch eine interne Map implementiert werden? Wenn ich irgendwo zwei shared_ptr erzeuge, die die gleiche Adresse besitzen, ist dann alles definiert?

[facepalm++]

Sone schrieb:

Soll eigentlich ein shared_ptr durch eine interne Map implementiert werden? Wenn ich irgendwo zwei shared_ptr erzeuge, die die gleiche Adresse besitzen, ist dann alles definiert?

facepalm++

[Sone]

Schon gut, ein ref counter, war doch klar.

[cooky451]

Vielleicht wenn mehrere Threads das gleiche Objekt besitzen?

[Kellerautomat]

Ich benutze shared_ptr z.B., um ungenutze Objekte in einen Cache zu werfen (Custom Deleter).

[Ethon]

Sone schrieb:

Soll eigentlich ein shared_ptr durch eine interne Map implementiert werden? Wenn ich irgendwo zwei shared_ptr erzeuge, die die gleiche Adresse besitzen, ist dann alles definiert?

Das ist der Grund warum std::shared_from_this existiert.
Wäre mit ner Map ja obsolet.

Obwohl das mit der Map garnicht mal so schlecht sein muss.

---

Edit. Um was zum Thema beizutragen:
Ich bastle gerade an einer Skriptsprache und nutze shared_ptr anstatt einem GC für die Speicherverwaltung. Vermutlich schlechtes Design.
Wollte es nur erwähnt haben.