《C++编程规范：101条规则、准则与最佳实践》——1.2:在高警告级别干净利落地进行编译

本节书摘来自异步社区出版社《c++编程规范：101条规则、准则与最佳实践》一书中的第1章，第1.2节，作者：【加】herb sutter , 【罗】andrei，更多章节内容可以访问云栖社区“异步社区”公众号查看。

摘要

高度重视警告：使用编译器的最高警告级别。应该要求构建是干净利落的（没有警告）。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。

讨论

编译器是你的朋友。如果它对某个构造发出警告，一般表明代码中存有潜在的问题。

成功的构建应该是无声无息的（没有警告的）。如果不是这样，你很快就会养成不仔细查看输出的习惯，从而漏过真正的问题（见第2条）。

排除警告的正确做法是：（1）把它弄清楚；然后，（2）改写代码以排除警告，并使代码阅读者和编译器都能更加清楚，代码是按编写者的意图执行的。

即使程序一开始似乎能够正确运行，也还是要这样做。即使你能够肯定警告是良性的，仍然要这样做。因为良性警告的后面可能隐藏着未来指向真正危险的警告。

示例

例1　第三方头文件。无法修改的库头文件可能包含引起警告（可能是良性的）的构造。如果这样，可以用自己的包含原头文件的版本将此文件包装起来，并有选择地为该作用域关闭烦人的警告，然后在整个项目的其他地方包含此包装文件。例如（请注意，各种编译器的警告控制语法并不一样）：

// ……在一个用户定义的allocator中未使用hint ……

// 警告：unused parameter 'localityhint

pointer allocate( size_type numobjects, const void *localityhint = 0 ) {

　return static_cast( mallocshared( numobjects * sizeof(t) ) );

}

// 消除了警告的新版本

pointer allocate( size_type numobjects, const void / localityhint */ = 0 ) {

　return static_cast( mallocshared( numobjects * sizeof(t) )　　);

}<code>`</code>

例3　“定义了从未使用过的变量”（variable defined but never used）。检查一下，确认并不是真正要引用该变量。（raii基于栈的对象经常会引起此警告的误报，见第13条。）如果确实不需要，经常可以通过插入一个变量本身的求值表达式，使编译器不再报警。（这种求值不会影响运行时的速度。）

// 警告：missing "return"

int fun( color c ) {

　switch( c ) {

　case red:　　return 2;

　case green:　　return 0;

　case blue:

　case black:　　return 1;

　}

　default:　　 assert( !"should never get here!" );　　// !"string" 的求值结果为false

　　　　　　　return -1;

例6　“有符号数/无符号数不匹配”（signed/unsigned mismatch）。通常没有必要对符号不同的整数进行比较和赋值。应该改变所操作的变量的类型，从而使类型匹配。最坏的情况下，要插入一个显式的强制转换。（其实不管怎么样，编译器都将为你插入一个强制转换，同时还会发出警告，因此还不如显式地先发而制之。）

例外情况

有时候，编译器可能会发出烦人的甚至虚假的警告（即纯属噪声的警告），但是又没有提供消除的方法，这时忙于修改代码解决这个警告可能是劳而无功或者事倍功半的。如果遇到了这种罕见的情形，作为团队决定，应该避免对纯粹无益的警告再做无用功：单独禁用这个警告，但是要尽可能在局部禁用，并且编写一个清晰的注释，说明为什么必须禁用。

参考文献

[meyers97] §48[8] ● [stroustrup94] §2.6.2