- 主题:从一段代码看编译器优化带来的编程挑战
有编译警告，应该是被无视了
我现在有个工程，近2千的编译警告，根本没人管，只要不出问题就不影响KPI.
我挑着改了一些。这应该是很多小项目的现状。
【 在 tis 的大作中提到: 】
: 怎么编译通过的？
--
修改:z16166 FROM 114.241.228.*
FROM 114.241.228.*
肯定不能算编译器的锅了
我之前在本版贴过一个没return语句的函数，这种UB被g++给优化成了死循环，理论上优化成啥都有可能。
【 在 gfkid 的大作中提到: 】
: 警告可以升级成error
: 项目不重视自然就越来越乱了
: 那也不是编译器的错误。
: ...................
--
FROM 114.241.228.*
UB啊，兄弟
【 在 gfkid 的大作中提到: 】
: 晕 你这个说的怎么感觉是编译器的锅
: :
--
FROM 114.241.228.*
这个函数没有写要return哪个变量或者常量，咋可能是RVO优化
【 在 foliver 的大作中提到: 】
: 原来的代码，这个编译器直接启用了rvo优化，result实际上被调用着直接替代了。所以一切正常。
:
--
FROM 114.241.228.*
为啥不是UB导致的优化呢？
【 在 foliver 的大作中提到: 】
: result是return的，一开始就判断了。
:
--
FROM 114.241.228.*
理想情况是这样
但实际又是另外一回事
【 在 tis 的大作中提到: 】
: 应该开除允许第一个警告的tech lead
--
FROM 114.241.228.*