为什么#if 0 vs #if (1 > 1)？答案

【问题标题】：Why #if 0 vs #if (1 > 1)?为什么#if 0 vs #if (1 > 1)？
【发布时间】：2016-08-31 19:26:11
【问题描述】：

我正在使用旧代码并发现：

#if (1 > 1)
//define some function
#endif

不确定，这与更典型的#if 0 有何不同，注释掉代码？有什么想法吗？

【问题讨论】：

可能，最初除了1s之外还有其他一些东西。然后它们逐渐变异。不，没有区别。
这是一个疯狂的猜测。我经常使用#if 0 在开发/调试期间禁用部分代码。在发布上述代码之前，我使用 grep 搜索 #if 0 以确保一切恢复正常。所以我会使用 #if 0 以外的其他东西来处理需要通过多个发布周期禁用的代码块。但是，我的情况是#ifdef something_that_cant_possibly_be_defined。
把它改成#if (!!(1 > 1) != 1) - 谜团很有趣。
好吧，受@user3386109 的启发，我可以想出另一个疯狂的想法：您可以通过#if (1<1)、#if (2<2) 等为禁用的块编号（用于识别）...
关于预处理器有很多奇怪的迷信，这看起来像是更奇怪的迷信之一。它当然没有明确定义的特殊含义（也就是说，除了它真正等同于#if 0），所以你的猜测和我们的一样好......

【解决方案1】：

这两个表达式都是假的，所以代码永远不会被编译。

以下是程序员不想使用明显的#if 0 预处理器指令来禁用一段代码的潜在解释：

程序员不希望grep '#if 0' 找到他的代码sn-p。
本地编码约定不允许#if 0 并可能使用脚本强制执行此规则。程序员找到了一个扭曲的解决方法。
一些程序员的编辑器（例如vim）将#if 0 部分着色为cmets，使用不同的预处理器表达式可以解决这个问题。
程序员可能认为在#if 之后需要一个布尔表达式。括号的使用支持了这种解释，但只有程序员才能知道。
原始代码有#if (OPTION > 1) 和OPTION 已更改为1 使用sed 脚本或其他一些全局文本替换方法。
程序员可能想要吸引下一位读者的注意力。出于幽默目的或其他一些晦涩的目标。在这种情况下实现的目标。
正如在某些 cmets 中所指出的，这可能是混淆代码以提高工作安全性的蹩脚尝试...为此，我建议使用 gets 运算符：#if (0 <- 1) 或爬行加法器：#if (1 <~~ 1).

【讨论】：

【解决方案2】：

我认为(1 > 1) 充当了读者的评论。这是一个笑脸或其他表情符号！ :-)

也可以写成(0>0) 或类似的。

【讨论】：