個人定義FALSE和TRUE是一個壞主意？ 為什么？

Question

我聽說過多次提到，自己定義這些宏不是一個好主意，但是我不明白為什么。 顯然，“ false”和“ true”是C ++標准的一部分，而“ FALSE”和“ TRUE”不是該標准的一部分。

但是，“ FALSE”和“ TRUE”在windows.h中被定義為宏，我已經習慣了它，實際上更喜歡它們，因為它們提醒我一個布爾值，在剝離了任何抽象之后，都被簡單地評估為位級別的整數。 無論如何，這是個人喜好，但是我想知道如果我想在程序中定義自己的宏，這真的不是一個好主意嗎？ 有什么令人信服的理由為什么不應該這樣做？

我在Stack Overflow上看到的一個答案是，該人員看到不滿的員工正在遍歷代碼並插入以下內容：

#define FALSE 1

但是，除了極度遙遠和愚蠢的事情之外，是否有充分的理由不這樣做？

編輯：感謝您的答案。 我理解並同意的原因如下：（來自Ulrich Eckhardt）

• 每個人都知道存在的常量/關鍵字true和false。
• 它與win32 API中的宏沖突，因此您的代碼將不可移植到該平台。
• int const FALSE = 1; 在沒有宏觀副作用的情況下將達到相同的效果。

（來自保羅·埃文斯）

• “您當然不希望它們為0和1，這會弄亂諸如調用同時帶有bool和int的函數重載的功能。”
• “因為如果可能的話，最好避免使用宏。在編譯器沒有外觀之前，預處理器就簡單地將所有宏替換為文本。因此，您失去了它們作為例如調試等信息的來源。”
• 將它們定義為常量表達式並避免使用宏

謝謝。

Answer 1

一堆原因：

• 與false相比， FALSE需要多按一次按鍵。
• 宏是邪惡的。
• int const FALSE = 1; 在沒有宏觀副作用的情況下將達到相同的效果。
• 它仍然看起來像一個宏。
• 每個人都知道存在的常量/關鍵字true和false 。
• 如果您和您是唯一在該代碼庫上工作的人，則只有這樣，它才足夠清楚。
• 它與win32 API中的宏沖突，因此您的代碼將不可移植到該平台。
• bool值不是int 。

Answer 2

因為如果可能，最好避免使用宏。 在編譯器甚至沒有外觀之前，預處理器只是簡單地將所有宏替換為文本。 因此，您會失去它們，無法將其作為例如調試等信息的來源。 同樣，您當然也不希望它們為0和1 ，這會弄亂諸如調用同時被bool和int重載的函數這樣的事情。 如果確實需要這些大寫的名稱，為什么不簡單地將它們定義為常量表達式，例如：

constexpr bool TRUE{true};
constexpr bool FALSE{false};

Answer 3

除以下之外，還提供了其他非常好的答案：

我是說如果我將其保留為標准，則布爾false為0， true為1，我認為這很標准。 實際上，據我所知，小寫的“ true”和“ false”分別等於1和0，這就是它填充字節的原因（我認為）

不行 這是一個可怕的錯誤。 不管布爾值最終將由CPU表示（ 可能是0和1），都存在布爾值不是整數的事實。

尤其是在模板（ operator<< ）和重載分辨率方面會出現陷阱。

首先，請考慮諸如std::vector類的類，該類對布爾類型實現不同的行為 。 在std::vector的情況下，您可能只會錯過優化，但是它可能遠不如優化（因為行為可能完全不同）。

第二，考慮一下：

void frob(char c, size_t repeats) {
  cout << "frob(char, size_t)" << endl;
}
void frob(char c, bool flag, size_t optional = 42) {
  cout << "frob(char, bool, size_t)" << endl;
}

#define TRUE 1

int main() {
  frob('a', true);
  // frob('a', TRUE); // COMPILATION ERROR
  return 0;
}

這個示例可能是非常人為的，在這種情況下，它還算不錯，因為存在一個編譯器錯誤，可以確切地說明問題所在，但可能不適用於所有實際情況。