Anwendungszweck von shared_ptr<T>?
-
Sone schrieb:
shared_ptr schrieb:
z.B.?
shared ownership.
Das ist ein Prinzip, kein Anwendungszweck.
-
Nun, mein Beispiel, wo ich es gebraucht habe, ist zu lang, um hier dargestellt zu werden.
-
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?
-
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?
-
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.
-
Vielleicht entspricht shared ownership ja nichts reellem. Sondern es ist ein hilfreiches Prinzip, dass bestimmte Designs einfacher [zu implementieren] macht.
-
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.
-
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.
-
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.
-
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?
-
Soll eigentlich ein
shared_ptrdurch eine interne Map implementiert werden? Wenn ich irgendwo zweishared_ptrerzeuge, die die gleiche Adresse besitzen, ist dann alles definiert?
-
Sone schrieb:
Soll eigentlich ein
shared_ptrdurch eine interne Map implementiert werden? Wenn ich irgendwo zweishared_ptrerzeuge, die die gleiche Adresse besitzen, ist dann alles definiert?facepalm++
-
Schon gut, ein ref counter, war doch klar.
-
Vielleicht wenn mehrere Threads das gleiche Objekt besitzen?
-
Ich benutze shared_ptr z.B., um ungenutze Objekte in einen Cache zu werfen (Custom Deleter).
-
Sone schrieb:
Soll eigentlich ein
shared_ptrdurch eine interne Map implementiert werden? Wenn ich irgendwo zweishared_ptrerzeuge, 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.
-
Sone schrieb:
Schon gut, ein ref counter, war doch klar.
Und die andere wichtige Implementierung?
-
Ethon schrieb:
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.Ich weiß. Bin gespannt, wie Du die zyklischen Referenzen findest. Halt uns auf dem Laufenden!
-
volkard schrieb:
Sone schrieb:
Schon gut, ein ref counter, war doch klar.
Und die andere wichtige Implementierung?
über verkettete Zeiger? macht das noch jemand?
-
Ich denke gerade nach, was verkettete Zeiger sein könnten. Fungiert der shared_ptr wie ein Listenknoten, und hält einen Zeiger auf den nächsten
shared_ptr? Dann würde use_count() aber eine lineare Komplexität haben, das ist AFAICS nicht verkraftbar.Edit: Das funktioniert auch gar nicht.
Edit²: Doch, das funktioniert. Der shared_ptr entfernt sich selbst aus der "Liste", sobald er zerstört wird. Anschließend prüft ein shared_ptr bei der Zerstörung immer, ob ein nächster
shared_ptrexistiert.Edit³: Wie zum Teufel entfernt man aus einer
forward_listein Element!? Wie wird der vorige Knoten verändert?Edit^4: Ich habe das Gefühl, das ist nicht das, was camper meinte. Zu hülf, camper! Was tatst du meinen?