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>?

z.B.?

shared ownership.

shared_ptr schrieb:

z.B.?

shared ownership.

Das ist ein Prinzip, kein Anwendungszweck.

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_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?

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.

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.

• 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 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.

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_ptr durch eine interne Map implementiert werden? Wenn ich irgendwo zwei shared_ptr erzeuge, die die gleiche Adresse besitzen, ist dann alles definiert?

facepalm++

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.

Schon gut, ein ref counter, war doch klar.

Und die andere wichtige Implementierung?

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!

Sone schrieb:

Schon gut, ein ref counter, war doch klar.

Und die andere wichtige Implementierung?

über verkettete Zeiger? macht das noch jemand?

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_ptr existiert.

Edit³: Wie zum Teufel entfernt man aus einer forward_list ein 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?

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.

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.