可以自由传递指标的 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才是谨慎的选择