Ein Steuerblock von a shared_ptr am Leben erhalten wird, solange es mindestens einen gibt weak_ptr gegenwärtig. Wenn der gemeinsam genutzte Zeiger mit erstellt wurde make_shared das impliziert, dass der gesamte Speicher des Objekts reserviert bleibt. (Das Objekt selbst wird ordnungsgemäß zerstört, aber da der Steuerblock und der Speicher für das Objekt in einem Block zugewiesen wurden, as make_shared tut, können sie nur zusammen freigegeben werden.)
Ist mein Verständnis richtig?
Es scheint, dass dieses Verhalten ein Problem darstellt, beispielsweise in der berühmten “Cache-Beispiel”. Der Speicher für die Objekte bleibt für immer allokiert.
Ist es ein Problem in praktischen Situationen? Soll das shared_ptr in einer solchen Situation mit einem Konstruktor erstellt werden (großes Objekt und beabsichtigte Verwendung weak_ptrS)?
Ja, aber denken Sie daran, dass viele “große” Objekte ihren eigenen Speicher dynamisch allokieren, z. B. ein Objekt, das aus a besteht std::vectorso dass dynamisch zugewiesener Speicher Wille freigegeben werden, wenn das Objekt zerstört wird. Sie müssen sich nur Sorgen machen, wenn die Größe des Objekts selbst groß ist, z. B. ein großes std::array.
– Chris Drew
20. August 2015 um 9:22 Uhr
Wenn Sie sich Sorgen um die Ausnahmesicherheit machen, können Sie verwenden make_unique stattdessen und konstruieren Sie dann a shared_ptr von deiner unique_ptr: z.B std::shared_ptr<BigObject> ptr = std::make_unique<BigObject>();
– Chris Drew
20. August 2015 um 9:46 Uhr
Ist mein Verständnis richtig?
Jawohl. Wenn dein weak_ptrs das (große) Objekt deutlich überdauern und Sie wenig Speicher haben, kann es sinnvoll sein, dies zu vermeiden make_shared.
Allerdings wird “groß” hier an gemessen sizeofund viele konzeptionell „große“ Objekte (z. B. die meisten Standardcontainer, außer std::array) sind nach dieser Metrik recht klein, da sie zusätzlichen Speicher zum Speichern ihres Inhalts zuweisen, der freigegeben wird, sobald das Objekt zerstört wird.
Ich habe das in VS2013 versucht und Sie haben völlig Recht. Der Destruktor wird aufgerufen, wenn der letzte shared_ptr zerstört wird, sodass alle anderen Objekte oder Speicher, die mit dem Objekt verknüpft sind, zerstört werden, aber wenn der shared_ptr mit make_shared erstellt wird, wird der Speicher nie zerstört, bis der letzte schwache_ptr ist.
Ich denke, es ist immer gut, Ihre schwachen_ptrs zu bereinigen oder zurückzusetzen, wenn lock() fehlschlägt, da es auch ohne make_shared immer noch etwas Speicher verwendet.
“es ist immer gut aufzuräumen oder zurückzusetzen (…)“Ja, aber nichts hindert die Implementierung daran, dies automatisch zu tun
– Neugieriger
12. Juni 2018 um 22:03 Uhr
8372300cookie-checkschwacher_ptr, make_shared und Speicherfreigabeyes
Ja, aber denken Sie daran, dass viele “große” Objekte ihren eigenen Speicher dynamisch allokieren, z. B. ein Objekt, das aus a besteht
std::vectorso dass dynamisch zugewiesener Speicher Wille freigegeben werden, wenn das Objekt zerstört wird. Sie müssen sich nur Sorgen machen, wenn die Größe des Objekts selbst groß ist, z. B. ein großesstd::array.– Chris Drew
20. August 2015 um 9:22 Uhr
Wenn Sie sich Sorgen um die Ausnahmesicherheit machen, können Sie verwenden
make_uniquestattdessen und konstruieren Sie dann ashared_ptrvon deinerunique_ptr: z.Bstd::shared_ptr<BigObject> ptr = std::make_unique<BigObject>();– Chris Drew
20. August 2015 um 9:46 Uhr