Question

当我检查某人的代码时，我喜欢强制执行无警告的政策。出现的任何警告都必须明确记录，因为有时候删除某些警告或者可能需要太多周期或内存等并不容易。

但是这个政策有一个缺点，那就是以有潜在危险的方式删除警告，即实际使用的方法隐藏了问题而不是修复它。

我最敏锐地意识到的是显式转换，可能会隐藏错误。

在C（++）中删除编译器警告的其他哪些有潜在危险的方法是我应该注意的？

Answer 1

const正确性会给初学者带来一些问题：

// following should have been declared as f(const int & x)
void f( int & x ) {
  ...
}

后：

// n is only used to pass the parameter "4"
int n = 4;
// really wanted to say f(4)
f( n );

Edit1：在某种程度上类似的情况下，将所有成员变量标记为 mutable ，因为当const正确性表明它确实不应该时，代码经常会更改它们。

Edit2：我遇到的另一个（可能来自Java程序员）是将throw（）规范应用到函数上，无论它们是否真的可以抛出。

Answer 2

嗯，有明显的方法 - 禁用部分代码的特定警告：

#pragma warning( disable : 4507 34 )

编辑：正如评论中指出的那样，有时需要在你知道警告没问题的情况下使用（如果它不是一个有用的功能，那么就没有理由把它放进去首先）。但是，它也是一种非常简单的方法来“忽略”代码中的警告，并且仍然可以静默编译，这就是最初的问题。

Answer 3

我认为这是一个微妙的问题。我的观点是应该彻底检查警告，看看代码是否正确/做了什么。但通常会有正确的代码会产生警告，并试图消除它们只是使代码卷积或强制以不太自然的方式重写。

我记得在之前的版本中，我有正确而稳定的代码，产生了一些警告，同事开始抱怨这一点。代码更干净，做了它的意图。最后，代码继续生成并带有警告。

此外，不同的编译器版本将产生不同的警告，因此当结果取决于编译器开发人员的情绪时，强制实施“无警告”策略变得毫无意义。

我想强调至少一次检查所有警告的重要性。

顺便说一句，我使用C和C ++开发嵌入式系统。

Answer 4

注释掉（或更糟糕的是，删除）生成警告的代码。当然，警告消失了，但你不仅仅是有可能最终得到的代码不符合你的意图。

Answer 5

我还强制执行无警告规则，但您不能在不仔细考虑的情况下删除警告。说实话，有时我会留下警告，因为代码是正确的。最终我以某种方式清理它，因为一旦你在构建中有十几个警告，人们就会停止关注它们。

您所描述的不是警告所特有的问题。我不能告诉你有多少次我发现崩溃的某些bug修复“我添加了几个NULL检查”。你必须找到根本原因：该变量应该是NULL吗？如果没有，为什么呢？

这就是我们进行代码审查的原因。

Answer 6

最大的风险是有人会花费数小时的开发时间来解决对代码没有影响的小警告。那将浪费时间。有时，更容易保持警告并添加一行注释来解释警告发生的原因。（直到有人有时间解决这些琐碎的警告。）

根据我的经验，解决琐碎的警告通常会为开发人员增加两天的工作量。这些可能会在截止日期之前和之后完成。