Anwendungszweck von shared_ptr<T>?

[dereinering]

§ 20.7.2.2.5/8 schrieb:

[ Note: use_count() is not necessarily efficient. — end note ]

[Nexus]

Genau für solche Fälle gibts ja shared_ptr::unique() .

Aber auch das braucht man recht selten. Ich hab unique() nur einmal bei einer ziemlich unkonventionellen Ressourcenverwaltung benötigt. Inzwischen ist mir aber klar geworden, dass es in vielen Fällen einfacher geht. Designs mit shared_ptr haben die Tendenz zu hoher Komplexität und Unklarheit über Besitzverhältnisse.

[shared_ptr]

Alles, was ich bisher gehört habe, fällt unter

shared_ptr schrieb:

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

Das macht man zwar nicht häufig, kommt aber von Zeit zu Zeit vor und ist aus meiner Sicht absolut legitim.

[cooky451]

cooky451 schrieb:

Vielleicht wenn mehrere Threads das gleiche Objekt besitzen?

[shared_ptr]

cooky451 schrieb:

cooky451 schrieb:

Vielleicht wenn mehrere Threads das gleiche Objekt besitzen?

Darunter konnte ich mir nur was vorstellen, wenn das Objekt immutable ist.

Könntest du kurz erklären?

[cooky451]

Angenommen man hat eine Art Cache (also einen Container) von schweren Daten. Jetzt soll ein Thread auf einem der Objekte in dem Cache Operationen ausführen. Dieser Thread arbeitet allerdings nur eine queue an jobs ab, die auch etwas länger sein kann. Man möchte verhindern, dass das Objekt aus dem Speicher gelöscht wird solange der Job darauf noch nicht abgearbeitet ist.

[hustbaer]

* COW Datenstrukturen.

* In Kombination mit weak_ptr: Thread-safe Signals/Slots Implementierungen.

Kellerautomat schrieb:

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

+1

Wobei man sie nicht gleich rauswerfen muss. Man kann sie im Deleter auch nur auf "nicht in Verwendung" setzen.

Und natürlich alle Cache-Ähnlichen Anwendungen wie Pools (Database-Connection Pool, ...).

[knivil]

shared_ptr schrieb:

Alles, was ich bisher gehört habe, fällt unter

shared_ptr schrieb:

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

Das macht man zwar nicht häufig, kommt aber von Zeit zu Zeit vor und ist aus meiner Sicht absolut legitim.

Du hast entweder nicht zugehoert und das angesprochene Video nicht angesehen.

[otze]

Ich hab hier shared_ptr im Einsatz um Sets und Subsets für unsere Datensatzklasse zu implementieren (subsets können ihre Eltern überleben)

[MichelRT]

z.B. wie bei uns eine Objektfabrik, die Datensätze aus verschiedenen Tabellen einer Datenbank in Objekte mapped und die erzeugten Objekte als weak_ptr cached.

Die Fabrik gibt die Objekte an ihre Besitzer weiter. Einige Objekte können dabei mehrere "Besitzer" haben. z.B. kann eine Maschinenachse mehrere Funktionen haben oder ein Maschineneinstellung hat mehrere Beobachter, ...

[asc]

Ich habe aktuell zwei Verwendungen vom shared_ptr:

1. Zwei nicht-modale Fenster, die auf die gleichen Daten verweisen (eines davon auch schreibend), und wo die Daten nach dem Schließen gelöscht werden.

2. Als Workaround für einen ansonsten nötigen massiven Umbau in einem älteren Projekt (Vorher Zeigerübergabe, aber es konnte der Fall eintreten, das der Zeiger zwischenzeitlich durch eine Aktualisierung ungültig wurde). Dies ist aber dem etwas verkorksten Design geschuldet.

[theta]

Ich verwende std::shared_ptr<..> im Zusammenhang mit Boost.Asio, wo ich shared_from_this() an die Handler übergebe um die Lebenszeit mindestens solange zu erhalten bis alle Handler completed sind.