软件错误不是问题，除非你们的业务承担不起错误的代价。哪个软件没 BUG

你们看开一点吧。软件改得怎么样不要在意，有一个同事在尽心尽力地做这种吃力不讨好的事情，只要别做到一半就中断，能持续跟着你们维护下去，就是福气。

【 在 toutouqi (toutouqi) 的大作中提到: 】
: 智能指针有人用的，只是老代码，结构简单的类改成用智能指针有时候显得并不智能，比如自定义的多维数组，比如简单字符串的parser及其语法树。没说这些语法不正统，只是觉得把时间花在追新标准方面浪费时间，也给原有开发者在维护代码的时候添了不少麻烦，毕竟谁也不能保
--
FROM 112.47.122.*

1 define vs const，是Effective cpp第二款的建议。主要是字符串替换与符号定义的区别。define没有任何优势。2000年以前的建议。 inline const只是个语法层的更新。


2 随机数是个专门的话题，我不懂。但你们要有自研算法，贸然换标准库不妥。


3 变量声明处给默认值，可以预防新增构造函数，不写初始化列表吧！语义上，或者设计表达上，这和默认值是场景无关的。构造函数的初始化列表，以及反序列化接口，每个都对应不同的使用场景，不同的默认值。


你的发言啊，我感觉主要还是情绪上的对抗。大多语法改动都是表层的问题，主要是为了传达设计意图、业务意图。如果只会把for改range based for，那是形式大于内容。
【 在 toutouqi 的大作中提到: 】
: 这方面有：把define的常量改成inline const，让把用了多年的随机数生成改成新标准里的random ...
--
FROM 1.80.243.*

你说得对，很多改动只是语法层面，对业务逻辑没有一毛钱帮助，比如做卷积运算的类里的buffer，智能指针替换普通指针有啥好处呢。当然也有情绪上的，如果你习惯用筷子，别人却把你的筷子换成叉子，而不管你用叉子会不会多花10分钟才能吃完，换谁也不会太高兴。
【 在 DoorWay 的大作中提到: 】
: 1 define vs const，是Effective cpp第二款的建议。主要是字符串替换与符号定义的区别。define没有任何优势。2000年以前的建议。 inline const只是个语法层的更新。
:
: 2 随机数是个专门的话题，我不懂。但你们要有自研算法，贸然换标准库不妥。
: ...................
--
FROM 221.220.229.*

“比如做卷积运算的类里的buffer，智能指针替换普通指针有啥好处呢”——没有明显bug和明显没有bug的区别。



如果这个buffer不被暴露出去，一般没问题。 改智能指针，unique会防止无意的copy ctor和copy assign。





【 在 toutouqi 的大作中提到: 】
: 你说得对，很多改动只是语法层面，对业务逻辑没有一毛钱帮助，比如做卷积运算的类里的buffer，智能指针替换普通指针有啥好 ...
--
FROM 36.45.40.*

不没修改类成员的方法有加const的，也有没加的，不统一，老代码都一般没加。arch确实不太关心每个人做的业务，也基本没可能把每个业务开发的算法都搞懂。但对业务开发，宁可希望有人能帮忙关注点业务，毕竟用户只能看到业务bug。
【 在 DoorWay 的大作中提到: 】
: 不统一就太蛋疼了。统一的Mat类多好。
:
: 接口的变量？没懂。我说的是，所有的类的成员方法，后面有const修饰吗？如果有，说明你们已经做得不错，战胜了非const派。代表当时进步的新力量。如果没有，说明你们就是完成业务为主的工程软件，软件工程本身考虑的比较少。你们这arch做得是基本工作。而且很可能是行业外的，业务敏感性一般，主要考虑软件工程本身的问题。
: ...................
--
FROM 221.220.229.*