我见过 C 中的定义
#define TRUE (1==1)
#define FALSE (!TRUE)
这有必要吗？与简单地将 TRUE 定义为 1，将 FALSE 定义为 0 相比，有什么好处？
【问题讨论】：
#define TRUE (’/’/’/’); #define FALSE (’-’-’-’)（取自 coding-guidelines.com/cbook/cbook1_1.pdf 第 871 页）
标签： c precompiler
如果编译器支持，这种方法将使用实际的boolean 类型（并解析为true 和false）。 （特别是 C++）
但是，最好检查 C++ 是否正在使用（通过__cplusplus 宏）并实际使用true 和false。
在 C 编译器中，这相当于 0 和 1。
（请注意，由于操作顺序，删除括号会破坏它）
【讨论】：
1==1 的结果是 int。 （见stackoverflow.com/questions/7687403/…。）
boolean 类型？
true 或 false。
__cplusplus 时使用 #define TRUE true 和 #define FALSE false。
答案是便携性。 TRUE 和 FALSE 的数值并不重要。 重要的是，像 if (1 < 2) 这样的语句的计算结果为 if (TRUE)，而像 if (1 > 2) 这样的语句的计算结果为 if (FALSE)。
当然，在 C 中，(1 < 2) 的计算结果为 1，(1 > 2) 的计算结果为 0，因此正如其他人所说，就编译器而言，没有实际区别。但是，通过让编译器根据自己的规则定义 TRUE 和 FALSE，您可以使它们的含义对程序员明确，并且您可以保证程序和任何其他库的一致性（假设其他库遵循 C 标准...您会感到惊讶）。
一些历史
一些 BASIC 将 FALSE 定义为 0 和 TRUE 定义为 -1。与许多现代语言一样，它们解释任何非零值为TRUE，但它们评估布尔表达式为-1。他们的NOT 操作是通过加 1 和翻转符号来实现的，因为这样做很有效。所以'NOT x'变成了-(x+1)。这样做的副作用是，像 5 这样的值计算为 TRUE，但 NOT 5 计算为 -6，这也是 TRUE！发现这种错误并不好玩。
最佳做法
鉴于 事实上 规则将零解释为 FALSE 而 任何 非零值被解释为 TRUE，您应该永远不要比较布尔值TRUE 或 FALSE 的表达式。例子：
if (thisValue == FALSE) // Don't do this!
if (thatValue == TRUE) // Or this!
if (otherValue != TRUE) // Whatever you do, don't do this!
为什么？因为很多程序员使用把ints 当作bools 对待的捷径。它们不一样，但编译器通常允许这样做。因此，例如，写是完全合法的
if (strcmp(yourString, myString) == TRUE) // Wrong!!!
看起来是合法的，编译器会很乐意接受它，但它可能不会做你想要的。那是因为strcmp()的返回值是
0 如果yourString == myString
yourString < myString
>0 如果yourString > myString
所以上面的行只有在yourString > myString 时才返回TRUE。
正确的做法是
// Valid, but still treats int as bool.
if (strcmp(yourString, myString))
或
// Better: lingustically clear, compiler will optimize.
if (strcmp(yourString, myString) != 0)
同样：
if (someBoolValue == FALSE) // Redundant.
if (!someBoolValue) // Better.
return (x > 0) ? TRUE : FALSE; // You're fired.
return (x > 0); // Simpler, clearer, correct.
if (ptr == NULL) // Perfect: compares pointers.
if (!ptr) // Sleazy, but short and valid.
if (ptr == FALSE) // Whatisthisidonteven.
您经常会在生产代码中发现其中一些“糟糕的示例”，许多有经验的程序员都对它们发誓：它们可以工作，有些比他们（迂腐？）正确的替代方案要短，而且这些习语几乎得到了普遍认可。但请考虑：“正确”版本的效率同样不低，它们保证可移植，甚至可以通过最严格的 linter，甚至新程序员也能理解它们。
这不值得吗？
【讨论】：
(1==1) 并不比 1 更便携。编译器自己的规则是 C 语言的规则，它对等式和关系运算符的语义是清晰明确的。我从未见过编译器会出错。
strcmp返回的值已知小于，等于或大于0。不保证为-1、0或1，野外有平台不'不要返回这些值以获得实施速度。所以如果strcmp(a, b) == TRUE 那么a > b 但反向暗示可能不成立。
(1==1) 和 1 都是 int 类型的常量表达式，值为 1。它们在语义上是相同的。我想你可以编写迎合不知道这一点的读者的代码，但它在哪里结束？
(1 == 1) 技巧对于以对 C 透明的方式定义 TRUE 很有用，但在 C++ 中提供了更好的类型。如果您使用称为“Clean C”的方言（编译为 C 或 C++）或编写可供 C 或 C++ 程序员使用的 API 头文件，则相同的代码可以解释为 C 或 C++。
在C翻译单元中，1 == 1与1的含义完全相同；并且1 == 0 与0 具有相同的含义。但是，在 C++ 翻译单元中，1 == 1 的类型为 bool。因此以这种方式定义的TRUE 宏可以更好地集成到 C++ 中。
如何更好地集成的一个示例是，例如，如果函数 foo 具有 int 和 bool 的重载，则 foo(TRUE) 将选择 bool 重载。如果 TRUE 只是定义为 1，那么它在 C++ 中将无法正常工作。 foo(TRUE) 将需要 int 重载。
当然，C99 引入了bool、true 和false，这些可以用于与 C99 和 C 一起使用的头文件中。
但是：
TRUE 和FALSE 定义为(0==0) 和(1==0) 的做法早于C99。如果您在混合 C 和 C++ 项目中工作，并且不需要 C99，请改为定义小写的 true、false 和 bool。
#ifndef __cplusplus
typedef int bool;
#define true (0==0)
#define false (!true)
#endif
话虽如此，0==0 技巧已（是？）被一些程序员使用，即使在从未打算以任何方式与 C++ 互操作的代码中也是如此。 这没有任何意义，表明程序员对布尔值在 C 中的工作方式存在误解。
如果 C++ 解释不清楚，这里有一个测试程序：
#include <cstdio>
void foo(bool x)
{
std::puts("bool");
}
void foo(int x)
{
std::puts("int");
}
int main()
{
foo(1 == 1);
foo(1);
return 0;
}
输出：
bool
int
关于 cmets 的问题，重载 C++ 函数如何与混合 C 和 C++ 编程相关。这些只是说明了类型差异。当编译为 C++ 时，希望 true 常量为 bool 的正当理由是为了干净的诊断。在最高警告级别，如果我们将整数作为bool 参数传递，C++ 编译器可能会警告我们转换。用 Clean C 编写的一个原因不仅是我们的代码更便携（因为它可以被 C++ 编译器理解，而不仅仅是 C 编译器），而且我们可以从 C++ 编译器的诊断意见中受益。
【讨论】：
TRUE 的两个定义在 C++ 下会有所不同，这一点并不明显。
#ifdef __cplusplus 来表达您的意图更清楚。
bool 和 int 之间的区别在实践中并不重要，因为它们可以相互隐式转换（并且在 C 实际上是“相同的”，但请注意引号），并且您真正需要在两者之间消除歧义 的情况并不多。 “不多” 可能太重了，“与使用模板和重载的代码相比要少得多” 可能会更好。
#define TRUE (1==1)
#define FALSE (!TRUE)
等价于
#define TRUE 1
#define FALSE 0
在 C 中。
关系运算符的结果是0 或1。 1==1 保证被评估为1，!(1==1) 保证被评估为0。
绝对没有理由使用第一种形式。请注意，第一种形式的效率并不低，因为几乎所有编译器都在编译时而不是在运行时计算常量表达式。根据这条规则这是允许的：
(C99, 6.6p2) “常量表达式可以在翻译期间而不是运行时进行计算，因此可以在常量可能存在的任何地方使用。”
如果您不对 TRUE 和 FALSE 宏使用文字，PC-Lint 甚至会发出一条消息（506，常量布尔值）：
对于 C，
TRUE应定义为1。然而，其他语言使用的数量不是 1，所以一些程序员认为!0是安全的。
同样在 C99 中，布尔宏 true 和 false 的 stdbool.h 定义直接使用文字：
#define true 1
#define false 0
【讨论】：
1==1 保证被评估为1
if(foo == true) 形式的代码很重要，这将从糟糕的实践变成完全错误的错误。
(x == TRUE) 中的危险可能与x 具有不同的真值。
除了 C++（已经提到）之外，另一个好处是静态分析工具。编译器将消除任何低效率，但静态分析器可以使用自己的抽象类型来区分比较结果和其他整数类型，因此它隐含地知道 TRUE 必须是比较的结果，不应假定为兼容一个整数。
显然 C 表示它们是兼容的，但您可以选择禁止故意使用该功能来帮助突出错误 - 例如，有人可能混淆了 & 和 &&，或者他们搞砸了他们的运算符优先级。
【讨论】：
if (boolean_var == (1 == 1)) 来捕获愚蠢的代码if (boolean_var == TRUE)，这要归功于(1 == 1) 节点的增强类型信息落入模式if (<*> == <boolean_expr>).
实际的区别是没有的。 0 被评估为false，1 被评估为true。您使用布尔表达式 (1 == 1) 或1 来定义true 的事实没有任何区别。他们都被评估为int。
请注意，C 标准库提供了用于定义布尔值的特定标头：stdbool.h。
【讨论】：
true 被评估为1，false 被评估为0。 C 不知道原生布尔类型，它们只是整数。
int 类型的结果，值为 0 或 1。 C 确实有一个实际的布尔类型（_Bool，在<stdbool.h> 中定义了一个宏bool，但这只是在C99 中添加的，它没有改变要使用的运算符的语义新类型。
_Bool，而<stdbool.h> 有#define bool _Bool。
1 == 1 被评估为int。已编辑。
我们不知道 TRUE 的确切值，编译器可以有自己的定义。所以你提供的是使用编译器的内部定义。如果您有良好的编程习惯但可以避免一些不良编码风格的问题，这并不总是必要的，例如：
如果 ((a > b) == TRUE)
如果您手动将 TRUE 定义为 1，而 TRUE 的内部值是另一个，这可能是一场灾难。
【讨论】：
> 运算符总是产生 1 表示真，0 表示假。任何 C 编译器都不可能出错。与TRUE 和FALSE 的平等比较是糟糕的风格；以上更清楚地写为if (a > b)。但是，不同的 C 编译器可以区别对待真假的想法是不正确的。
通常在 C 编程语言中，1 定义为真，0 定义为假。因此，为什么您经常看到以下内容：
#define TRUE 1
#define FALSE 0
但是，任何不等于 0 的数字在条件语句中也会被评估为真。因此，通过使用以下内容：
#define TRUE (1==1)
#define FALSE (!TRUE)
您可以通过使 false 等于任何不正确的内容来明确表明您试图安全行事。
【讨论】：