您会使用 num%2 或 num&1 来检查数字是否为偶数吗？

Question

好吧，至少有两种低级方法可以确定给定的数字是否为偶数：

 1. if (num%2 == 0) { /* even */ } 
 2. if ((num&1) == 0) { /* even */ }

我认为第二个选项更加优雅和有意义，这就是我通常使用的方法。但这不仅仅是品味问题；实际性能可能会有所不同：通常按位运算（例如此处的逻辑与）比 mod（或 div）运算效率更高。当然，您可能会说有些编译器无论如何都能够优化它，我同意......但有些则不能。

另一点是，对于经验不足的程序员来说，第二个可能有点难以理解。对此，我的回答是，如果这些程序员花那么短的时间来理解此类语句，那么可能只会使每个人受益。

你怎么认为？

仅当 num 是无符号整数或具有二进制补码表示形式的负数时，给定的两个片段才是正确的。 - 正如一些评论正确指出的那样。

Answer 1

我首先为了可读性而编码，所以我这里的选择是 num % 2 == 0。这比num & 清楚得多。 1 == 0 。我会让编译器为我担心优化，并且仅在分析显示这是一个瓶颈时进行调整。任何其他事情都为时过早。

我认为第二种选择更加优雅和有意义

我强烈不同意这一点。数字是偶数是因为它的同余模二为零，而不是因为它的二进制表示以某个位结尾。二进制表示是一个实现细节。依赖实现细节通常是一种代码味道。正如其他人指出的那样，在使用补码表示的机器上测试 LSB 会失败。

另一点是，对于经验不足的程序员来说，第二个可能有点难以理解。对此，我的回答是，如果这些程序员花那么短的时间来理解此类语句，那么可能只会使每个人受益。

我不同意。我们都应该通过编码来使我们的意图更加清晰。如果我们正在测试均匀性，代码应该表达这一点（并且注释应该是不必要的）。同样，测试模 2 的一致性比检查 LSB 更能清楚地表达代码的意图。

而且，更重要的是，细节应该隐藏在 isEven 方法中。所以我们应该看到 if(isEven(someNumber)) { // details } 并且在 isEven 的定义中只看到一次 num % 2 == 0代码>.

Answer 2

如果您要说某些编译器不会优化 %2，那么您还应该注意某些编译器对有符号整数使用补码表示。在该表示中，&1 对于负数给出了错误的答案。

那么你想要什么 - 在“某些编译器”上运行缓慢的代码，或者在“某些编译器”上错误的代码？每种情况下不一定使用相同的编译器，但这两种类型都极为罕见。

当然，如果num是无符号类型，或者C99定宽整数类型之一（int8_t等，要求是2的补码），那么这不是问题。在这种情况下，我认为 %2 更优雅、更有意义，而 &1 是一种 hack，可以想象，有时对于性能来说可能是必要的。例如，我认为 CPython 不会进行这种优化，对于完全解释的语言也是如此（尽管解析开销可能会使两个机器指令之间的差异相形见绌）。不过，如果 C 或 C++ 编译器在可能的情况下没有这样做，我会感到有点惊讶，因为如果之前没有的话，那么在发出指令时这是理所当然的。

一般来说，我想说，在 C++ 中，你完全受编译器优化能力的支配。标准容器和算法具有 n 级间接寻址，其中大部分在编译器完成内联和优化后消失。一个像样的 C++ 编译器可以在早餐前处理带有常量值的算术，而一个不像样的 C++ 编译器无论你做什么都会产生垃圾代码。

Answer 3

我定义并使用“IsEven”函数，这样我就不必考虑它，然后我选择一种方法或另一种方法，然后忘记如何检查某些东西是否为偶数。

唯一挑剔/警告的是，我只是说，通过按位运算，您假设了一些关于二进制数字表示的内容，但您不是模数。您正在将数字解释为十进制值。这几乎可以保证适用于整数。然而，考虑到模运算适用于双精度数，但按位运算则不然。

Answer 4

您关于性能的结论是基于流行的错误前提。

由于某种原因，您坚持将语言操作翻译成“明显的”机器对应项，并根据该翻译得出性能结论。在这种特殊情况下，您得出的结论是，C++ 语言的按位与 & 运算必须通过按位与 机器运算来实现，而模 %< /code> 操作必须以某种方式涉及机器除法，据称这会更慢。如果有的话，这种方法的用途也非常有限。

首先，我无法想象现实生活中的 C++ 编译器会以这种“字面”方式解释语言操作，即通过将它们映射到“等效”机器操作。主要是因为人们常常认为等效的机器操作根本不存在。

当涉及到以立即数作为操作数的基本操作时，任何有自尊心的编译器总是会立即“理解”num & 1 和整数 num 的 num % 2 执行完全相同的操作，这将使编译器为两个表达式生成完全相同的代码。当然，性能会完全相同。

顺便说一句，这不叫“优化”。根据定义，优化是指编译器决定偏离抽象 C++ 机器的标准行为，以生成更高效的代码（保留程序的可观察行为）。在这种情况下没有偏差，这意味着没有优化。

此外，在给定的机器上，实现两者的最佳方式很可能既不是按位与，也不是除法，而是其他一些专用的机器特定指令。最重要的是，很可能根本不需要任何指令，因为特定值的偶数/奇数可能会通过处理器状态标志或类似的东西“免费”公开那。

换句话说，效率论是无效的。

其次，回到最初的问题，确定值的偶数/奇数的更好方法肯定是 num % 2 方法，因为它从字面上实现了所需的检查（“根据定义”），并清楚地表达了检查纯粹是数学的事实。也就是说，它清楚地表明我们关心数字的属性，而不是表示的属性（就像num & 1<的情况一样） /code> 变体）。

num &当您想要访问数字的值表示形式时，应保留 1 变体。使用此代码进行偶数/奇数检查是一种非常值得怀疑的做法。

Answer 5

人们多次提到任何现代编译器都会为这两个选项创建相同的程序集。这让我想起前几天在某处看到的 LLVM 演示页面，所以我想我应该给它走吧。我知道这只不过是轶事，但它确实证实了我们的预期：x%2 和 x&1 的实现相同。

我还尝试使用 gcc-4.2.1 (gcc -S foo.c) 编译这两个文件，生成的程序集是相同的（并粘贴在这个答案的底部）。

对第一个程序进行编程：

int main(int argc, char **argv) {
  return (argc%2==0) ? 0 : 1;
}

结果：

; ModuleID = '/tmp/webcompile/_27244_0.bc'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

define i32 @main(i32 %argc, i8** nocapture %argv) nounwind readnone {
entry:
    %0 = and i32 %argc, 1       ; <i32> [#uses=1]
    ret i32 %0
}

对第二个程序进行编程：

int main(int argc, char **argv) {
  return ((argc&1)==0) ? 0 : 1;
}

结果：

; ModuleID = '/tmp/webcompile/_27375_0.bc'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

define i32 @main(i32 %argc, i8** nocapture %argv) nounwind readnone {
entry:
    %0 = and i32 %argc, 1       ; <i32> [#uses=1]
    ret i32 %0
}

GCC 输出：

.text
.globl _main
_main:
LFB2:
  pushq %rbp
LCFI0:
  movq  %rsp, %rbp
LCFI1:
  movl  %edi, -4(%rbp)
  movq  %rsi, -16(%rbp)
  movl  -4(%rbp), %eax
  andl  $1, %eax
  testl %eax, %eax
  setne %al
  movzbl  %al, %eax
  leave
  ret
LFE2:
  .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
  .set L$set$0,LECIE1-LSCIE1
  .long L$set$0
LSCIE1:
  .long 0x0
  .byte 0x1
  .ascii "zR\0"
  .byte 0x1
  .byte 0x78
  .byte 0x10
  .byte 0x1
  .byte 0x10
  .byte 0xc
  .byte 0x7
  .byte 0x8
  .byte 0x90
  .byte 0x1
  .align 3
LECIE1:
.globl _main.eh
_main.eh:
LSFDE1:
  .set L$set$1,LEFDE1-LASFDE1
  .long L$set$1
ASFDE1:
  .long LASFDE1-EH_frame1
  .quad LFB2-.
  .set L$set$2,LFE2-LFB2
  .quad L$set$2
  .byte 0x0
  .byte 0x4
  .set L$set$3,LCFI0-LFB2
  .long L$set$3
  .byte 0xe
  .byte 0x10
  .byte 0x86
  .byte 0x2
  .byte 0x4
  .set L$set$4,LCFI1-LCFI0
  .long L$set$4
  .byte 0xd
  .byte 0x6
  .align 3
LEFDE1:
  .subsections_via_symbols

Answer 6

这一切都取决于上下文。如果它是低级别的系统上下文，我实际上更喜欢 &1 方法。在许多此类上下文中，“偶数”对我来说基本上意味着低位为零，而不是可以被二整除。

然而：你的一个衬垫有一个错误。

您不能将

if( (x&1) == 0 )

后者

if( x&1 == 0 )

与 x 与 1==0 进行与运算，即它与 x 与 0 进行与运算，得到 0，当然，它总是评估为 false。

因此，如果您完全按照您的建议进行操作，那么所有数字都是奇数！

Answer 7

任何现代编译器都会优化模运算，因此速度不是问题。

我想说使用模会让事情更容易理解，但是创建一个使用 x & 的 is_even 函数。 1 方法为您提供两全其美的方法。

Answer 8

他们都非常直观。

我倾向于 num % 2 == 0，但我确实没有偏好。当然，就性能而言，这可能是一个微观优化，所以我不会担心它。

Answer 9

我花了几年坚持认为，任何合理的编译器都值得其在磁盘上消耗的空间，将num % 2 == 0优化为num & 1 == 0 。然后，通过分析不同原因的反汇编，我有机会实际验证我的假设。

事实证明，我错了。 Microsoft Visual Studio，一直到 2013 版本，都会为 num % 2 == 0 生成以下目标代码：

    and ecx, -2147483647        ; the parameter was passed in ECX
    jns SHORT $IsEven
    dec ecx
    or  ecx, -2
    inc ecx
$IsEven:
    neg ecx
    sbb ecx, ecx
    lea eax, DWORD PTR [ecx+1]

是的，确实如此。这是在发布模式下，启用了所有优化。无论是针对 x86 还是 x64 进行构建，您都会获得几乎相同的结果。你可能不会相信我；我自己都几乎不相信。

它基本上完成了您对 num & 的期望。 1 == 0：

not  eax                        ; the parameter was passed in EAX
and  eax, 1

相比之下，GCC（早至 v4.4）和 Clang（早至 v3.2）确实如此人们所期望的，为两个变体生成相同的目标代码。但是，根据 Matt Godbolt 的交互式编译器，ICC 13.0.1 也超出了我的预期。

当然，这些编译器并没有错。这不是一个错误。有很多技术原因（正如其他答案中充分指出的那样）为什么这两个代码片段不相同。这里肯定有一个“过早优化是邪恶的”论点。诚然，我花了很多年才注意到这一点，这是有原因的，即便如此，我也只是错误地偶然发现了它。

但是，就像 Doug T. 所说的，最好在你的代码中定义一个 IsEven 函数。某个地方的库可以正确处理所有这些小细节，这样您就不必再考虑它们，并保持代码的可读性。如果您经常以 MSVC 为目标，也许您会像我一样定义这个函数：

bool IsEven(int value)
{
    const bool result = (num & 1) == 0;
    assert(result == ((num % 2) == 0));
    return result;   
}

Answer 10

这两种方法都不是显而易见的，特别是对于刚接触编程的人来说。您应该使用描述性名称定义一个内联函数。您在其中使用的方法并不重要（微观优化很可能不会以明显的方式使您的程序更快）。

不管怎样，我相信 2) 更快，因为它不需要除法。

Answer 11

我不认为模数使事情更具可读性。 两者都有道理，而且两个版本都是正确的。计算机以二进制存储数字，因此您可以只使用二进制版本。

编译器可能会用高效版本替换模版本。但这听起来像是更喜欢取模的借口。

在这种非常特殊的情况下，两个版本的可读性是相同的。刚接触编程的读者可能甚至不知道可以使用模 2 来确定数字的偶数性。读者必须自行推论。他可能甚至不知道模运算符！

在推导语句背后的含义时，甚至可以更容易地阅读二进制版本：（

if( ( num & 1 ) == 0 ) { /* even */ }
if( ( 00010111b & 1 ) == 0 ) { /* even */ }
if( ( 00010110b & 1 ) == 0 ) { /* odd */ }

我使用“b”后缀只是为了澄清，它不是 C/C++）

对于模版本，您必须仔细检查如何操作在其详细信息中定义（例如，检查文档以确保 0 % 2 是您所期望的）。

二进制 AND 更简单并且没有歧义！

只有运算符优先级可能是二元运算符的陷阱。但这不应该成为避免使用它们的理由（总有一天，即使是新程序员也会需要它们）。

Answer 12

在这一点上，我可能只是增加了噪音，但就可读性而言，模选项更有意义。如果你的代码不可读，那么它实际上毫无用处。

另外，除非这是在资源确实紧张的系统（我认为是微控制器）上运行的代码，否则不要尝试针对编译器的优化器进行优化。