第1条 在高警告级别干净利落地进行编译

 
<script type="text/javascript">function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script>

<script src="http://wz.csdn.net/javascripts/vote.js" type="text/javascript"></script> style="MARGIN-TOP: 0px; FLOAT: left" border="0" marginwidth="0" framespacing="0" marginheight="0" src="http://wz.csdn.net/vote.aspx?t=%u7B2C1%u6761%u3000%u5728%u9AD8%u8B66%u544A%u7EA7%u522B%u5E72%u51C0%u5229%u843D%u5730%u8FDB%u884C%u7F16%u8BD1%20-%20soulgreen%u7684%u4E13%u680F%20-%20CSDNBlog&u=http%3A//blog.csdn.net/soulgreen/archive/2007/11/21/1897119.aspx" frameborder="0" noresize="noresize" width="54" scrolling="no" height="75">  第1条　在高警告级别干净利落地进行编译    <script src="http://blog.csdn.net/count.aspx?ID=1897119&Type=Rank" type="text/javascript"></script>   

讨论

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

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

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

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

示例

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

// 文件： myproj/my_lambda.h —— 包装了 Boost 的 lambda.hpp

// 应该总是包含此文件，不要直接使用 lambda.hpp。

// 注意：我们的构建现在会自动检查“ grep lambda.hpp <srcfile>”。

// Boost.Lambda 会产生一些已知无害的编译器警告。

// 在改正以后，我们将删除以下的编译指示，但此头文件仍然存在。

//

#pragma warning(push)              // 仅禁用此头文件

  #pragma warning(disable:4512)

  #pragma warning(disable:4180)

 #include <boost/lambda/lambda.hpp>

#pragma warning(pop)              // 恢复最初的警告级别

 

例 2  “ 未使用的函数参数 ”（ Unused function parameter ）。检查一下，确认确实不需要使用该函数参数（比如，这可能是一个为了未来扩展而设的占位符，或者是代码没有使用的标准化函数签名中的一个必需部分）。如果确实不需要，那直接删除函数参数名就行了。

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

// 警告：“ unused parameter 'localityHint”

pointer allocate( size_type numObjects, const void *localityHint = 0 ) {

  return static_cast<pointer>( mallocShared( numObjects * sizeof(T) ) );

}

// 消除了警告的新版本

pointer allocate( size_type numObjects, const void * /* localityHint */ = 0 ) {

  return static_cast<pointer>( mallocShared( numObjects * sizeof(T) )     );

}

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

// 警告：“ variable 'lock' is defined but never used”

void Fun() {

  Lock lock;

  // _……

}

// 可能消除了警告的新版本

void Fun() {

  Lock lock;

 lock;

  // _……

}

例 4  “ 变量使用前可能未经初始化 ”（ Variable may be used without being initialized ） 。初始化变量（见第19条）。

例 5  “ 遗漏了 return 语句 ”（ Missing return ） 。有时候编译器会要求每个分支都有 return语句，即使控制流可能永远也不会到达函数的结尾（比如：无限循环， throw语句，其他的返回形式等）。这可能是一件好事，因为有时候你仅仅是 认为控制不会运行到结尾。例如，没有 default情况的 switch语句不太适应变化，应该加上执行 assert( false ) 的 default情况（见第68条和第90条）。

// 警告： missing "return"

int Fun( Color c ) {

  switch( c ) {

  case Red:       return 2;

  case Green:   return 0;

  case Blue:

  case Black:    return 1;

  }

}

// 消除了警告的新版本

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

例外情况

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