2

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

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

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

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

4

6 回答 6

6

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() 规范附加到函数上，无论它们是否真的可以抛出。

于 2009-07-01T08:03:14.323 回答
5

好吧，有一个明显的方法 - 禁用部分代码的特定警告：

#pragma warning( disable : 4507 34 )

编辑：正如评论中所指出的，有时有必要在您知道警告正常的情况下使用（如果它不是一个有用的功能，就没有理由把它放在第一个地方）。但是，这也是一种“忽略”代码中的警告并仍然让它静默编译的非常简单的方法，这就是最初的问题所在。

于 2009-07-01T07:58:02.180 回答
2

我认为这是一个微妙的问题。我的观点是，应该彻底检查警告以查看代码是否正确/是否符合预期。但通常有正确的代码会产生警告，而试图消除它们只会使代码复杂化或以不太自然的方式强制重写。

我记得在之前的版本中，我有正确而可靠的代码，产生了几个警告，同事们开始抱怨这个。代码更简洁，并按照预期进行。最后，代码带着警告继续生产。

此外，不同的编译器版本会产生不同的警告，因此当结果取决于编译器开发人员的心情时，强制执行“无警告”策略变得更加没有意义。

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

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

于 2009-07-01T10:44:32.767 回答
1

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

于 2009-07-01T08:39:23.563 回答
1

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

您所描述的不是警告独有的问题。我无法告诉你有多少次我看到有人对崩溃的错误修复是“我添加了几个 NULL 检查”。您必须找到根本原因：该变量是否应该为 NULL？如果不是，为什么会这样？

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

于 2009-07-01T12:46:24.767 回答
0

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

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

于 2009-07-01T09:38:27.050 回答