- 主题:大家对开发人员写带类的C怎么看
因为并不牛x好用
我们这里有个同事用，又搞不清哪里引用了，内存一直放不掉，查找起来超级痛苦。
【 在 stub 的大作中提到: 】
: 为什么不用智能指针这么牛x好用的东西
--
FROM 117.140.37.*
函数内部用是可以用智能指针的，那个案例是模块间用了，内存申请得还很大。在我这里内部用内存池的，异常的时候内存池析构
【 在 stub 的大作中提到: 】
: 那如果产生异常这种情况， 你们一般怎么释放资源的
--
FROM 180.138.183.*
不是智能指针，写出来就崩了，根本进不到下一步。
bug要尽早暴露才容易抓。
等到写得差不多了才发现有问题，那工作量乘十倍算少的。
【 在 here080 (hero080) 的大作中提到: 】
: 这是你们整个架构的问题。如果不是智能指针，那岂不是错误引用了？
--
FROM 119.132.56.*
这个不崩的可能太小了呀，多跑几次就会崩了。而且就算不崩，内容也是非法的，很容易被发现
【 在 here080 的大作中提到: 】
: 错误引用不一定崩。你对C++有误解。
: 另外，你同事是滥用shared_ptr了吧？
: 把带所有权的裸指针无脑换成unique_ptr是对的。
: ...................
--
FROM 14.150.97.*
你太高看那帮菜鸟了，只要程序不崩，能出正确结果，内存泄漏他们才不管，非要在系统级内存泄漏大了导致不能复现的闪崩才会去看问题，那时候问题又不是他们这种水平能轻易解决的。如果有对象所有权和生命周期的概念，裸指针都不会有问题。
对于稍复杂的流程，对象创建和对象析构一般不在同一函数，那样我看不出unique_ptr有解决问题的优势。考虑其只可移动不可复制，那帮菜鸟只会嫌烦而不是考虑这样有什么好处。
【 在 here080 (hero080) 的大作中提到: 】
: 非法内容可能直接造成错误数据而不是崩。错误数据放到系统上没等到多跑几个版本可能公司就破产了。
: 当然，你观察的实际情况多数会崩这是没错的。但是万一某个情况下不会崩，就是一个超级大的且难以被发现的BUG。相比之下内存漏泄反而是小事。
: 回到最初，这里最大的问题还是你们的系统架构。使用unique_ptr虽然不能直接解决你们的架构问题，但是可以强迫使用者开始有“对象所有权”和“生命周期”的概念。这才是解决问题的关键。
: ...................
--
FROM 14.16.5.*
系统指软件系统，模块上一层的概念，不是指操作系统
内存申请都不检查空的，啥事不能发生啊
【 在 DoorWay 的大作中提到: 】
: 「系统级内存泄漏大了导致不能复现的闪崩」
: 你这话就是玄学，是流行于程序员的神秘主义，非常有害。
: 系统级内存泄漏，定义是什么？ 没有释放系统资源吗？
: ...................
--
修改:somebody FROM 14.16.5.*
FROM 14.16.5.*
你知道招个靠谱的cpp开发多难么？
【 在 stub 的大作中提到: 】
: 你们这是什么单位啊...
--
FROM 14.16.5.*
没错啊，我的意思就是用更容易出现的崩溃，防止低水平开发把漏洞保护起来，等到联调的时候就很难抓。还不如让他在module级别开发就崩掉fix掉。
【 在 here080 (hero080) 的大作中提到: 】
: 我没看出来这层意思。在我的意识里，系统级的泄漏导致崩溃在不用智能指针项目里更容易出现。
--
FROM 119.132.59.*
用unique_ptr要把ptr搬来搬去地，那帮菜鸟才不会给自己找麻烦呢...
个个都是用shared_ptr偷懒，妄图放弃对内存的管理。
【 在 here080 (hero080) 的大作中提到: 】
: 你的思路大方向是对的。直接崩掉的程序远比UB要好得多。
: 但是使用裸指针在这一点上并不会带来任何比unique_ptr更优的结果。
: 对内存问题而言使用unique_ptr是最好的保护。
: ...................
--
FROM 119.132.58.*
泪流满面..
你好好设计规划出活的速度肯定比不上号称敏捷开发的糙快猛啊，销售部门又不考虑这玩意。
【 在 fanci (大葡萄) 的大作中提到: 】
: 又回到那个问题了：代码质量的价值难以在短期体现。先上线了再说！什么？crash？重启！加server！加冗余！failover！
--
FROM 119.132.58.*