我听过多次提到自己定义这些宏是一个坏主意,但我不明白为什么 . 显然,'false'和'true'是C标准的一部分,'FALSE'和'TRUE'不是标准的一部分 .
但是,'FALSE'和'TRUE'被定义为windows.h中的宏,我已经习惯了它,并且实际上更喜欢它们,因为它们提醒我,在剥离任何抽象之后,布尔值被简单地评估为位级的整数 . 无论如何,这是个人偏好,但我想知道如果我想在我的程序中定义自己的宏真的是一个坏主意吗?任何有说服力的理由为什么不应该这样做?
我在Stack Overflow上看到的一个答案是,该人已经看到心怀不满的员工通过代码并插入如下内容:
#define FALSE 1
但除了极其遥远和愚蠢的东西之外,还有什么好的理由不去吗?
编辑:谢谢你的回答 . 我理解并同意的理由是:(来自Ulrich Eckhardt)
-
每个人都知道现有常量/关键字是真还是假 .
-
它与win32 API中的宏冲突,因此您的代码将无法移植到该平台 .
-
int const FALSE = 1;没有宏观副作用会达到同样的效果 .
(来自Paul Evans)
-
"you certainly don't want them to be 0 and 1, this will mess up things like calling functions overloaded with both bool and int."
-
"Because macros are best avoided if possible. The preprocessor simply text-replaces all macro before the compiler even has a look-see. So you lose them as a source of information in say, debugging, etc."
-
将它们定义为常量表达式并避免使用宏
谢谢 .
3 回答
因为如果可能的话,最好避免使用宏 . 在编译器甚至具有外观之前,预处理器只是文本替换所有宏 . 所以你丢失它们作为信息来源,比如说,调试等等 . 你当然也不希望它们是
0
和1
,这会搞乱调用函数重载的事情bool
和int
. 如果你真的必须有这些大写的名字,为什么不简单地将它们定义为常量表达式,如:一堆原因:
FALSE
需要再输入一次按键,而不是false
.宏是邪恶的 .
如果没有宏观副作用,
int const FALSE = 1;
将达到相同的效果 .但它仍然看起来像一个宏 .
每个人都知道有现有的常量/关键字
true
和false
.如果您和唯一的人是唯一一个在该代码库上工作的人,那么它就变得足够清晰了 .
它与win32 API中的宏冲突,因此您的代码将无法移植到该平台 .
A
bool
不是int
.另外,为了回应以下非常好的答案:
No . 这是一个可怕的错误 . 无论一个布尔将最终由CPU表示(可能是0和1),只有 a boolean is not an integer 的事实 .
特别是在模板(
operator<<
)和重载分辨率方面会出现陷阱 .首先,考虑一个实现different behavior for boolean types的类,如
std::vector
. 在std::vector
的情况下,您可能只会错过优化,但可能会比这更糟糕(因为行为可能完全不同) .对于第二个,请考虑这个:
这个例子可能是非常人为的,在这种情况下它甚至不是那么糟糕,因为有一个编译器错误显示出错了什么,但这可能不适用于所有现实世界的情况 .