我無法理解此警告的以下行爲。「警告C4800不同情況下的不同行爲：'int'：將值強制爲bool'true'或'false'」
case 1:
bool read = (33 & 3) ; //No Warning issued by vs 2013
case 2:
int b = 33;
bool read = (b & 3) ; //Now compiler is generating C4800 warning.
爲什麼編譯器的情況下，2產生警告，而它不在的情況下發出任何警告1.
在第一種情況下，您從表達式創建布爾變量。這是可能的
std::cout << std::is_constructible<decltype((33 & 3)), bool>::value<<std::endl; // output: 1
在第二種情況下，你從表達式構造int變量。這種表達int
std::cout << typeid(b & 3).name() << std::endl; // output: i
而且，類型最後，使用隱式類型轉換從int到bool，並得到警告。
關於兩種情況下，你別說，他們的區別在於，在一個情況下，整個積分值是編譯時常量（或者至少可以簡單地歸結爲一個）。也許假設是用常量表達式進行初始化不應該觸發這個警告？我會檢查供應商的錯誤跟蹤系統以獲取更多信息。
但是，實際上我會忽略甚至禁用此警告。考慮測試一個位的情況：bool negative = byte & 0x80;。這段代碼就是我稱之爲慣用代碼，它會產生一個警告。對我來說，這是證明這個警告不好的證據。
C4800是的性能警告 - 在運行時將整數強制爲bool會產生成本。
它與邏輯正確性無關。
coersion（和警告）最常見的情況是當你使用整數代碼（VC++中的BOOL）與布爾值進行交互時。
第一段代碼中的編譯時強制不會導致運行時開銷，所以沒有警告。
爲了擺脫的警告，擺脫脅迫：
bool read = (b & 3) != 0;
我仍然會說編譯器的警告是無稽之談，因爲您建議作爲替代方案的代碼可能與它自己生成的代碼相同，但這不會導致警告。實際上，我似乎記得，這個非常古老的警告只是留在原地，並且因爲一些遺留原因而使用這些文本，即使是MS的人也會忽略/禁用它。 –
嘛'字節和0x80'不返回一個bool。要實際避免警告而不是忽略它，請使用'byte＆0x80！= 0'，這會使轉換顯式化。 –
我完全意識到這一點，@Matthäus。重點是這是測試一般的常用方法，如果編譯器給我提出了一些警告，實際上它沒有幫助。同樣，我不會比較指向null的指針以查看它們是否爲null，我只是在需要布爾表達式的地方使用它們並使用隱式轉換。 –
'bool valid = ptr;'其中'ptr'是一些指針會在VC中觸發相同的警告，另一方面'if（i）'對於某些'int i'不會。所以VC提倡在表達不是上下文可轉換的情況下進行顯式轉換。實際上這與'explicit operator bool'是一致的。 –