- 主题:这种情况下我该不该把unique_ptr改成shared_ptr?
我觉得你这个类的设计有问题
A有个一个m_b，用unique_ptr表示独有，那m_b里的callback也只能是原来的那个object，那为什么要用A*呢？用A&不是更安全
【 在 fly2never 的大作中提到: 】
: Class A 持有 Class B
: class A {
: public:
: ...................
--
FROM 36.23.69.*
如果用A&，就根本不存在用shared_ptr还是weak_ptr的问题了吧，言下之意就是callback在B的生存期一直是有效的
【 在 here080 的大作中提到: 】
: A*还是A&跟楼主讨论的问题完全无关。
:
--
FROM 36.23.69.*
如果要一定保证不失效，就只有使用shared_ptr或者weak_ptr
楼主的问题是不是要牺牲效率而从代码级别保证访问callback不会出问题
如果callback有可能会在B的生存期内失效，那就不需要讨论，直接上weak_ptr
如果callback确保不会在B的生存期失效，并且从楼主的描述来看，callback是在B创建的时候就建立了，并且就是拥有m_b的那个A的instance，那用A&在设计上会更明确一些
如果callback指向的不是拥有m_b的那个A的instance，那用raw pointer只有从构架上保证callback的生存期比m_b长了。
需不需要用weak_ptr，还是却决于类的使用环境。如果有一个统一的container来管理所有A instance的生存周期，那用raw pointer就可以。要在完全去耦合，从类的设计上就保证不出问题，肯定是要损失效率的
【 在 here080 的大作中提到: 】
: A&只是一个必须初始化且无法重定向的A*而已
: A&引用的东西跟指针指向的一样，是否失效不是语言本身保证的。
:
--
FROM 36.23.69.*
效率肯定是要降低的，至于降低多少，会不会影响最终程序效果，要看你这个类用在什么地方，如果是高频高密集使用，你用shared_ptr和weak_ptr肯定是会影响最终效果的。
我觉得和你这个有可比性的是，google的protobuf，里面有很多set_allocated_xxx,之类的接口，google的也没有从代码级别保证一定不会访问失效地址，只是说大家要注意。
当然，这个和程序员的价格有关系。。。
【 在 fly2never 的大作中提到: 】
: 感谢详细回答.
: 确实如你所说. 如果我能100%确认不会失效, 那么用 A& 是最好的. 这样语义明确, 不用到处判空.
: 但是项目大了之后, 很多人写代码, 我在想要不要 强制一个团队规范, 就是不用在成员变量里面使用 raw pointer, 如果有, 就用weak_ptr来代替. 这样就100%保证了不会出问题, 但是代价是性能会降低.
: ...................
--
FROM 36.23.69.*
并没有
【 在 fly2never 的大作中提到: 】
: 还有一个问题, 如果A& 失效的话, 有没有类似断言的方法, 可以一步准确定位下来?否则后面各种崩溃, 很难检查W
:
--
FROM 36.23.69.*