Anwendungszweck von shared_ptr<T>?
-
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?
-
Höh? Ein shared_ptr legt im Normalfall ein atomic_int auf dem Heap an und zählt damit.
Edit³: Wie zum Teufel entfernt man aus einer forward_list ein Element!? Wie wird der vorige Knoten verändert?
Geht ja per Iterator nicht. Man iteriert durch und merkt sich halt immer den letzten Knoten.
Edit: Stop. Eine schlaue Implementierung könnte ja im Iterator den letzten Knoten halten. Dann geht's.
volkard schrieb:
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!
Hab da ein paar Ideen die aber alle recht imperformant klingeń.
Vermutlich wird's ein GC, der steht sowieso auf der Muss-man-mal-implementiert-haben Liste.
-
Ethon schrieb:
Höh? Ein shared_ptr legt im Normalfall ein atomic_int auf dem Heap an und zählt damit.
Ja, das ist die Standardimplementierung, ein ref counter, wie bereits erwähnt.
-
camper schrieb:
über verkettete Zeiger? macht das noch jemand?
Gebe zu, ist stark im Abnehmen.
-
Sone schrieb:
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.Da aber in 100 Jahren Informatikgeschichte ausßer zum Debuggen kein use_count() auf shared_pointers benötigt wurde, ist das jetzt nicht wirklich das zwingende Argument.