C++小知識(shí):盡可能使用枚舉類
靜態(tài)代碼分析工具可簡(jiǎn)化編碼過程,檢測(cè)出錯(cuò)誤并幫助修復(fù)。PVS-Studio 是一個(gè)用于 C/C++ 的靜態(tài)代碼分析工具。該團(tuán)隊(duì)檢測(cè)了 200 多個(gè) C/C++ 開源項(xiàng)目,包括了 Unreal Engine、Php、Haiku、Qt 和 Linux 內(nèi)核等知名項(xiàng)目。
下面這個(gè) Bug 是在 Source SDK 的源代碼中發(fā)現(xiàn)的。
錯(cuò)誤代碼:
這種錯(cuò)誤的例子代碼量都非常大,我盡可能地選取其中最小的一部分,但是很抱歉,代碼看起來依舊很冗長(zhǎng)。
enum PhysGunPickup_t { PICKED_UP_BY_CANNON, PUNTED_BY_CANNON, PICKED_UP_BY_PLAYER, }; enum PhysGunDrop_t { DROPPED_BY_PLAYER, THROWN_BY_PLAYER, DROPPED_BY_CANNON, LAUNCHED_BY_CANNON, }; void CBreakableProp::OnPhysGunDrop(...., PhysGunDrop_t Reason) { .... if( Reason == PUNTED_BY_CANNON ) { PlayPuntSound(); } .... }
解釋:
Reason 變量是屬于枚舉類型 PhysGunDrop_t,卻用它和屬于另一個(gè)枚舉類型的常量作比較,這種比較顯然是個(gè)邏輯錯(cuò)誤。
但是這種 bug 模式很普遍,我甚至在像 Clang、TortoiseGit 和 Linux Kernel 這種項(xiàng)目中都有碰到過。
為什么會(huì)如此頻繁?因?yàn)樵跇?biāo)準(zhǔn)C++中,枚舉類型本來就不是類型安全的。到底什么該跟什么做比較,很容易讓人混淆。
正確代碼:
我不太確定這段代碼的正確版本應(yīng)該是什么樣的,我猜想 PUNTED_BY_CANNON 應(yīng)該用 DROPPED_BY_CANNON 或者 LAUNCHED_BY_CANNON 來替代。此處就用 LAUNCHED_BY_CANNON 來代替了。
if( Reason == LAUNCHED_BY_CANNON ) { PlayPuntSound(); }
建議:
如果你是用C++寫代碼,還沒碰到過這種bug,算你幸運(yùn);我強(qiáng)烈建議你從現(xiàn)在開始在代碼中使用“枚舉類”。
對(duì)于C++11中的一些新特性,我沒有太多信心。就拿auto關(guān)鍵字來說吧,我相信如果頻繁使用的話,會(huì)有很多壞處的。 我是這么看的:比起寫代碼,程序員會(huì)花更多的時(shí)間閱讀代碼,所以我們必須確保程序的可讀性很強(qiáng)。 C語言中, 所有變量都必須在函數(shù)的一開始就聲明,那么在函數(shù)的中間或者末尾編輯代碼時(shí),沒那么容易推測(cè)出某個(gè)Alice變量到底是什么意思。這也是為什么變量的命名規(guī)范會(huì)這么多樣化? 例如,前綴命名法PfAlice就代表指向浮點(diǎn)數(shù)的指針。
C++中你可以隨時(shí)隨地聲明變量,這是一種很好的編碼風(fēng)格。因而使用前后綴命名也不再那么受歡迎了。接著auto關(guān)鍵字出現(xiàn)了,直接導(dǎo)致程序員又開始使用各種各樣很難理解的構(gòu)造形式, 諸如auto Alice= FOO()
; 之類的。 Alice?誰是TM的Alice?(為保留原文本意,此處翻譯稍有不文明)
很抱歉,又偏離我們的主題了。 我想告訴大家的是一些新的特性都有它的好壞兩面性。 但是對(duì)于“枚舉類”, 我堅(jiān)信使用它有百利而無一害。
在使用枚舉類的時(shí)候,必須明確指出指定的常量屬于哪個(gè)枚舉類型,以免在代碼中出現(xiàn)錯(cuò)誤。使用枚舉類更新后的代碼如下:
enum class PhysGunDrop_t { DROPPED_BY_PLAYER, THROWN_BY_PLAYER, DROPPED_BY_CANNON, LAUNCHED_BY_CANNON, }; void CBreakableProp::OnPhysGunDrop(...., PhysGunDrop_t Reason) { .... if( Reason == PhysGunDrop_t::LAUNCHED_BY_CANNON ) { PlayPuntSound(); } .... }
說真的,修復(fù)舊代碼的確會(huì)有一定困難,但我強(qiáng)烈推薦你們?cè)诖a中使用枚舉類,你的項(xiàng)目定會(huì)從中受益。
我覺得在這兒詳細(xì)介紹枚舉類沒有多大意義,有興趣的可以自己去了解一下的。
這個(gè)錯(cuò)誤是用靜態(tài)代碼分析工具 PVS-Studio 檢測(cè)到的,錯(cuò)誤信息為:V556 對(duì)不同枚舉類型的值進(jìn)行比較:Reason == PUNTED_BY_CANNON
。
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接
相關(guān)文章
淺析設(shè)計(jì)模式中的代理模式在C++編程中的運(yùn)用
這篇文章主要介紹了設(shè)計(jì)模式中的代理模式在C++編程中的運(yùn)用,代理模式最大的好處就是實(shí)現(xiàn)了邏輯和實(shí)現(xiàn)的徹底解耦,需要的朋友可以參考下2016-03-03C++實(shí)現(xiàn)LeetCode(347.前K個(gè)高頻元素)
這篇文章主要介紹了C++實(shí)現(xiàn)LeetCode(347.前K個(gè)高頻元素),本篇文章通過簡(jiǎn)要的案例,講解了該項(xiàng)技術(shù)的了解與使用,以下就是詳細(xì)內(nèi)容,需要的朋友可以參考下2021-08-08C++使用TinyXml實(shí)現(xiàn)讀取XMl文件
常見C/C++?XML解析器有Tinyxml、XERCES、squashxml、xmlite、pugxml、libxml等等,本文為大家介紹的是使用TinyXml實(shí)現(xiàn)讀取XMl文件,需要的可以參考一下2023-06-06解析C語言基于UDP協(xié)議進(jìn)行Socket編程的要點(diǎn)
這篇文章主要介紹了C語言通過UDP協(xié)議進(jìn)行Socket編程的要點(diǎn),文中還提到了相關(guān)ARP與ICMP協(xié)議的作用,需要的朋友可以參考下2016-02-02C++實(shí)現(xiàn):螺旋矩陣的實(shí)例代碼
螺旋矩陣是指一個(gè)呈螺旋狀的矩陣,它的數(shù)字由第一行開 始到右邊不斷變大,向下變大, 向左變大,向上變大,如此循環(huán)。2013-03-03