删除编译器警告的危险方法？

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:在一个有点类似,标志着所有成员变量为可变的,因为当const正确性说,这实在不应该你的代码经常改变它们.

编辑2:我遇到的另一个(可能来自Java程序员)是将throw()规范应用到函数上,无论它们是否实际抛出.

Answer 2

好吧,有一种显而易见的方法 - 禁用部分代码的特定警告:

#pragma warning( disable : 4507 34 )

编辑:正如评论中指出的那样,有时需要在你知道警告没问题的情况下使用(如果它不是一个有用的功能,那么就没有理由把它放在第一个地点).但是,它也是一种非常简单的方法来"忽略"代码中的警告,并且仍然可以静默编译,这就是最初的问题.