靜態(tài)代碼分析工具可簡化編碼過程，檢測出錯誤并幫助修復。PVS-Studio 是一個用于 C/C++ 的靜態(tài)代碼分析工具。該團隊檢測了 200 多個 C/C++ 開源項目，包括了 Unreal Engine、Php、Haiku、Qt 和 Linux 內核等知名項目。于是他們每天分享一個錯誤案例，并給出相應建議。

這個 bug 是在 Unreal Engine 4 的源代碼中發(fā)現(xiàn)的。

錯誤代碼：

void FSlateNotificationManager::GetWindows( TArray< TSharedRef<SWindow> >& OutWindows) const{ for( auto Iter(NotificationLists.CreateConstIterator());    Iter; Iter++ ) {  TSharedPtr<SNotificationList> NotificationList = *Iter;  .... }}

解釋：

如果不讀標題的話，你可能很難發(fā)現(xiàn)這段代碼里的問題。第一眼看上去這段代碼完全正確，其實它并不完美。沒錯，我指的是后自增運算符 Iter++ 。 我們應該盡量使用前自增運算符而不是后自增運算符，即用 ++ Iter 代替 Iter++ 。 為什么要這么做，有什么有實際價值？下面我會詳細解釋。

正確代碼：

void FSlateNotificationManager::GetWindows( TArray< TSharedRef<SWindow> >& OutWindows) const{ for( auto Iter(NotificationLists.CreateConstIterator());    Iter; ++Iter) {  TSharedPtr<SNotificationList> NotificationList = *Iter;  .... }}

建議：

前綴和后綴形式之間的區(qū)別是眾所周知的。我希望它們內部結構的區(qū)別（告訴了我們運算法則）大家也是清楚的。如果你有使用過運算符重載的話，肯定已經意識到了。沒有用過的話，我在這兒簡單地解釋一下（用過運算符重載的可以跳過下面關于運算符重載的例子）。

前自增運算符改變了對象的狀態(tài)并返回對象改變后的狀態(tài)，不需要創(chuàng)建臨時對象。下面是前自增運算符的例子：

MyOwnClass& operator++(){ ++meOwnField; return (*this);}

后自增運算符也改變了對象的狀態(tài)但是返回的是對象改變前的狀態(tài)，并且需要創(chuàng)建一個臨時對象。下面是后自增運算符重載的例子：

MyOwnClass operator++(int){ MyOWnCLass tmp = *this; ++(*this); return tmp;}

看到上面這段代碼，你會發(fā)現(xiàn)有一個額外的操作，就是要創(chuàng)建一個臨時對象，在實踐中這點太重要了！

現(xiàn)在的編譯器做代碼優(yōu)化的時候非常智能，如果沒有用處，是不會隨便創(chuàng)建臨時對象的。這就是為什么在發(fā)布版中我們很難發(fā)現(xiàn)i++和++i的區(qū)別。

但是在調試模式下進行程序調試的時候就是另一回事了，這時候你會看到性能上有很大差別。

有一些例子可以估計調試版本中使用前自增和后自增運算符的代碼運行時間，我們可以看到使用后綴形式所用時間幾乎是前綴的四倍。

有人會說：”那又怎么樣？反正發(fā)布版都是一樣的。”，這種想法說對也對說不對也不對。通常我們會花更多的時間做單元測試和調試程序，所以大多數時間都在調試版本下工作，誰也不想浪費時間在那兒等吧？

關于“對于迭代器，我們是否應該用前自增運算符(++i)來代替后自增運算符(i++)？”這個問題，我想認真地回答: “是的，真應該這么做”。 你會發(fā)現(xiàn)在調試版本中速度大大提升。 如果迭代器很復雜的話，這么做的好處更是顯而易見了。

這個錯誤是用靜態(tài)代碼分析工具 PVS-Studio 發(fā)現(xiàn)的，錯誤信息為：V803 性能下降。 如果iter是迭代器的話，使用前自增運算符會更高效，使用++iter代替iter++.

總結

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