可以自由傳遞指標的 std::shared_ptr 比傳統指標要安全許多
但即使如此也還是有cyclic reference的問題存在
網路上查到的解法幾乎都用 weak_ptr 來處理
但是我怎麼看都不覺得這算解法
因為它無法阻止物件被釋放
之所以要使用 std::shared_ptr 就是希望抓著指標就一定能使用所指的物件
我自己目前的做法是對物件分層級
只有高層物件可以擁有指標指向下層物件
確保不會連成一圈
這方式我還沒看到明顯的問題
但是這種自我約束的行為還是很不可靠
一個不小心包成std::function之類的東西然後亂丟可能就發生
而且一旦出現cyclic也很難查覺
因為它就只是安靜的咬著記憶體不放
不知道有沒有更理想的處理方式?
或者有比 shared_ptr 更好的工具也可以介紹一下

你怎麼不先從設計開始討論？會用到 std::shared_ptr大部分情況就是懶得好好設計你有好好釐清 ownership 嗎?std::shared_ptr 的 share 是 share responsibility不是 share object, 首先為了 share object 用std::shared_ptr 就算是誤用, 為了讓 std::functionown object 你有必須這樣做的理由嗎? 還是 lifetime還沒分析過就直接用了?那首先就要問到, 為什麼你要連絡的對象會比你還早被解構? 是不是你在基本上就無法掌握控制每個物件的生命週期, 導致只能用最簡單的方法: 讓 shared_ptr 幫你處理這些複雜事?一般分享物件都是用指標/參考, 為什麼你要用智慧指標

一般軟工把這個現象稱為 "設計不良"

你的case可以參考一下是否該使用std::unique_ptrshared_ptr的確是有這種ownership(肇因於設計不良)不明的case，這種其實把權責劃分一下滿容易解決的很多人把shared_ptr當scope ptr在用 但是別忘了使用的時候，總要記得這ptr總該要有個ownership的像你預期未來會在用到 那你就該有個controller處理這個真的決定要cleanup時的邏輯 ownership要歸給該control請注意shared_ptr不是GC 不要老用GC觀點思考這問題你很多思考上都是把它當GC了 這兩個是完全不同的概念

確實unique_ptr才是謹慎的選擇