對于C++編程的老鳥來說，有時候他們喜歡把一些東西按照編譯器的工作原理進行改寫，以便提高代碼的運行效率。這么做確實高明，也能體現(xiàn)出程序員的水平，但是這么做也是有風險的。因為有時候你可能會因為一些簡單的筆誤，而造成非常難以察覺的錯誤。本文就給出了類似的例子。

這個Bug 出現(xiàn)在MySQL源代碼中。

錯誤代碼：

static int rr_cmp(uchar *a,uchar *b)
{
 if (a[0] != b[0])
  return (int) a[0] - (int) b[0];
 if (a[1] != b[1])
  return (int) a[1] - (int) b[1];
 if (a[2] != b[2])
  return (int) a[2] - (int) b[2];
 if (a[3] != b[3])
  return (int) a[3] - (int) b[3];
 if (a[4] != b[4])
  return (int) a[4] - (int) b[4];
 if (a[5] != b[5])
  return (int) a[1] - (int) b[5];   <<<<====
 if (a[6] != b[6])
  return (int) a[6] - (int) b[6];
 return (int) a[7] - (int) b[7];
}

說明：

這是一個在對代碼段進行拷貝粘貼時出現(xiàn)的典型錯誤。程序員很可能是把“if (a[1] != b[1]) (int) a[1] – (int) b[1];” 這段代碼拷貝了好幾遍（然后手動改數(shù)組下標），用來實現(xiàn)一個循環(huán)。不過程序員忘記把其中某一行的數(shù)組下標 1 改成 5。結(jié)果就是函數(shù)有時候能返回正確的值（，有的時候則不行），這種錯誤是很難偵測的。事實上這個錯誤的確很難捕捉，在我們用 PVS-Studio 掃描 MySQL 源代碼之前，所有其他的測試都沒能發(fā)現(xiàn)這個錯誤。

正確的代碼：

if (a[5] != b[5])
 return (int) a[5] - (int) b[5];

盡管之前的代碼看上去整潔易讀，但是程序員還是很有可能漏看這個錯誤。因為這個代碼塊的內(nèi)部結(jié)構(gòu)很相似，所以你本能地會一掃而過，而不會特別集中注意力去閱讀代碼。

之所以把代碼寫成這樣，很可能是程序員想盡可能地優(yōu)化代碼。他（或她）想手動“展開循環(huán)”（來進行優(yōu)化）。不過我想在這兒可不是個好主意。

首先，我很懷疑程序員是不是真的能通過這種方法達到效果。要知道，現(xiàn)代編譯器已經(jīng)相當智能了，如果真的能優(yōu)化程序性能，（編譯器）自動就會完成展開循環(huán)的優(yōu)化。

其次，由于嘗試進行優(yōu)化卻造成了代碼中出現(xiàn) bug。如果程序員一開始能老老實實寫一個簡單循環(huán)，那么犯錯誤的幾率就會降低很多。

我建議把這個方法寫成這樣：

static int rr_cmp(uchar *a,uchar *b)
{
 for (size_t i = 0; i < 7; ++i)
 {
  if (a[i] != b[i])
   return a[i] - b[i];
 }
 return a[7] - b[7];
}

這種寫法有兩個優(yōu)勢：

• 1.這個函數(shù)更容易閱讀和理解。
• 2.編寫代碼時，降低犯錯幾率。

至于性能方面，我敢說這個版本不會比之前寫得很長的那個版本慢。

這個推薦的方法實際上表達了下面的意思：代碼要簡單易讀。簡單的代碼通常即是正確的代碼。不要去做編譯器的工作——例如，（手動）展開循環(huán)。編譯器很明確知道自己該做什么，并不需要你的幫助。手動代碼優(yōu)化工作只針對某些特定的關(guān)鍵代碼，而且只在分析器已經(jīng)確認這些代碼是瓶頸以后，才可能恰當。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請查看下面相關(guān)鏈接

最新評論