- 主题:这种情况下我该不该把unique_ptr改成shared_ptr?
并没有
【 在 fly2never 的大作中提到: 】
: 还有一个问题, 如果A& 失效的话, 有没有类似断言的方法, 可以一步准确定位下来?否则后面各种崩溃, 很难检查W
:
--
FROM 36.23.69.*
dangling pointer崩溃不一定崩溃在原地吧?很可能崩溃在一个遥远的地方(内存损坏?)
【 在 here080 (hero080) 的大作中提到: 】
: 崩溃了不就知道发生啥了？
: 你想定位什么？这个不是一处程序问题，是整个一大块程序共同的问题。
--
FROM 218.200.160.*
这种当然没办法了。UB行为你无法预测。
不过在debug mode里应该是有办法在原地爆炸的。
【 在 fly2never (逆飞的鱼) 的大作中提到: 】
: 标 题: Re: 这种情况下我该不该把unique_ptr改成shared_ptr?
: 发信站: 水木社区 (Mon Jul 26 11:55:26 2021), 站内
:
: dangling pointer崩溃不一定崩溃在原地吧?很可能崩溃在一个遥远的地方(内存损坏?)
: 【 在 here080 (hero080) 的大作中提到: 】
: : 崩溃了不就知道发生啥了？
: : 你想定位什么？这个不是一处程序问题，是整个一大块程序共同的问题。
:
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 218.200.160.*]
--
FROM 76.126.252.*
所有reference都用weak_ptr，然后用的时候都得先lock？
这都不是性能问题。先问问你团队成员愿不愿意写这种“C++”吧。
而且你这么滥用shared_ptr，出现循环引用是必然的。
【 在 fly2never 的大作中提到: 】
: 感谢详细回答.
: 确实如你所说. 如果我能100%确认不会失效, 那么用 A& 是最好的. 这样语义明确, 不用到处判空.
: 但是项目大了之后, 很多人写代码, 我在想要不要 强制一个团队规范, 就是不用在成员变量里面使用 raw pointer, 如果有, 就用weak_ptr来代替. 这样就100%保证了不会出问题, 但是代价是性能会降低.
: ...................
--
FROM 114.86.93.*
Google style，个人觉得最大的坑，下划线命名，与get函数不匹配，特麻烦。
【 在 here080 的大作中提到: 】
: 这是错误的方式。事实上大项目里滥用shared_ptr只会造成更多的问题。
: 你可以使用一些编译工具和测试工具来减少可能出现的dangling问题。
: 出于代码安全考虑，我建议你学习google style
: ...................
--
修改:lushan5436 FROM 223.104.3.*
FROM 223.104.3.*
建议你们转到rust，呵呵
这种规范只会帮倒忙
这里的用例太明显了，a拥有b，b只是引用a
【 在 fly2never 的大作中提到: 】
: 感谢详细回答.
: 确实如你所说. 如果我能100%确认不会失效, 那么用 A& 是最好的. 这样语义明确, 不用到处判空.
: 但是项目大了之后, 很多人写代码, 我在想要不要 强制一个团队规范, 就是不用在成员变量里面使用 raw pointer, 如果有, 就用weak_ptr来代替. 这样就100%保证了不会出问题, 但是代价是性能会降低.
: ...................
--
FROM 123.112.22.*