枚舉依託整數布爾轉換

Question

在我的編譯器項目，我有去像

enum Result { 
    No, 
    Maybe, 
    Yes 
}; 

我已經把No明確在第一位置，這樣我可以依靠的布爾評價false枚舉。如果我的編譯器不確定某些事情，並且必須等到事件發生，那麼其分析函數將返回Maybe。使用像

if(!typesEqual(t1, t2)) { 
    diagnose(types_unequal) << t1 << t2; 
} 

我不知道你或你的公司是否認爲它不好的風格不比較No明確

if(typesEqual(t1, t2) == No) { /* ... */ } 

明確的比較似乎羅嗦給我，但依靠隱布爾轉換莫名其妙讓我感到內疚。你之前有過這種感覺嗎，你是如何處理它的？

Answer 1

我會感到內疚爲好，因爲從閱讀你會想到布爾typesEqual()表達式返回一個Maybe上述的代碼？它會迴歸真實嗎？也許！它會返回錯誤嗎？也許！我們不知道 - 這是枚舉的整個點。這就是爲什麼明確地與No進行比較是有意義的，儘管它比較冗長。

Answer 2

因爲轉換爲布爾型是明確定義的，所以我通常不使用整數或指針類型的零的顯式比較。

但是，我總是使用枚舉的明確比較，以防萬一有人改變了枚舉的定義。畢竟，你永遠無法確定有人不會改變枚舉。

依靠枚舉數的基礎數值看起來似乎是一個壞主意。

Answer 3

我不喜歡的是它是不對稱的。

E.g.你真正想要的地方是

if(typesEqual(t1, t2) == Yes) { 
    do_something(); 
} 

，但偶然你寫

if(typesEqual(t1, t2)) { 
    do_something(); 
} 

它看起來有點怪/醜，你可以使用布爾伎倆沒有，但不是爲是。

我想我會解決它通過重命名功能tryCompareTypes(t1, t2)，並改變你的枚舉

enum Result { 
    Maybe, 
    No, 
    Yes 
}; 

所以tryCompareTypes()返回0，如果「失敗」來明確決定類型是否相等，否則返回要麼是否，要麼是，兩者都不是零，因此表示「成功」。

Answer 4

這似乎與Boost.Tribool相似。 Tribool支持在bool中使用條件語句的轉換，這似乎表明，在這種情況下，隱式轉換爲bool並不壞，至少根據Boost組織（我認爲這是相當合理的）。