在我看来，这是一个被伪装成技术问题的行为面试问题。有些公司会这样做——他们会问一个任何有能力的程序员都应该很容易回答的技术问题，但是当面试者给出正确答案时，面试官会告诉他们他们错了。

公司想看看你在这种情况下会作何反应。你是否会因为自我怀疑或害怕让面试官不高兴而安静地坐在那里，不强调自己的答案是正确的?或者你愿意挑战一个你知道是错误的权威人士吗?他们想看看你是否愿意坚持自己的信念，以及你是否能以一种机智和尊重的方式做到这一点。

根据人们花费在测试、证明和回答这个非常直接的问题上的时间和精力来判断，我认为这两者都因为提出这个问题而变得非常缓慢。

所以花更多的时间在这上面…

虽然(2)很荒谬，因为，

While(1)和While (true)在历史上被用于创建一个无限循环，该循环预计在循环中的某个阶段根据一定会发生的条件调用break。

1只是为了总是求值为真，因此，说while(2)和说while(1 + 1 == 2)一样愚蠢，后者也会求值为真。

如果你想完全傻一点，就用:-

while (1 + 5 - 2 - (1 * 3) == 0.5 - 4 + ((9 * 2) / 4.0)) {
    if (succeed())
        break;
}

我认为面试官犯了一个错别字，这并不影响代码的运行，但如果他故意使用2只是为了表现得奇怪，那么在他把奇怪的语句贯穿你的代码，使其难以阅读和使用之前解雇他。

这两个循环都是无限的，但我们可以看到哪个循环每次迭代需要更多的指令/资源。

使用gcc，我编译了以下两个程序，以不同的优化级别进行汇编:

int main(void) {
    while(1) {}
    return 0;
}

int main(void) {
    while(2) {}
    return 0;
}

即使没有优化(-O0)，两个程序生成的程序集也是相同的。因此，两个循环之间没有速度差异。

作为参考，下面是生成的程序集(使用gcc main.c -S -masm=intel并带有优化标志):

o0:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    push    rbp
    .seh_pushreg    rbp
    mov rbp, rsp
    .seh_setframe   rbp, 0
    sub rsp, 32
    .seh_stackalloc 32
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

o1群:

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .text
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

-O2和-O3(相同输出):

    .file   "main.c"
    .intel_syntax noprefix
    .def    __main; .scl    2;  .type   32; .endef
    .section    .text.startup,"x"
    .p2align 4,,15
    .globl  main
    .def    main;   .scl    2;  .type   32; .endef
    .seh_proc   main
main:
    sub rsp, 40
    .seh_stackalloc 40
    .seh_endprologue
    call    __main
.L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

事实上，为循环生成的程序集对于每个级别的优化都是相同的:

 .L2:
    jmp .L2
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

重要的部分是:

.L2:
    jmp .L2

我不太懂汇编，但这显然是一个无条件循环。jmp指令无条件地将程序重置回. l2标签，甚至不将值与true进行比较，当然，它会立即再次这样做，直到程序以某种方式结束。这直接对应于C/ c++代码:

L2:
    goto L2;

编辑:

有趣的是，即使没有优化，下面的循环都在汇编中产生完全相同的输出(无条件jmp):

while(42) {}

while(1==1) {}

while(2==2) {}

while(4<7) {}

while(3==3 && 4==4) {}

while(8-9 < 0) {}

while(4.3 * 3e4 >= 2 << 6) {}

while(-0.1 + 02) {}

甚至令我惊讶的是:

#include<math.h>

while(sqrt(7)) {}

while(hypot(3,4)) {}

对于用户定义函数，事情变得更加有趣:

int x(void) {
    return 1;
}

while(x()) {}

#include<math.h>

double x(void) {
    return sqrt(7);
}

while(x()) {}

At -O0, these two examples actually call x and perform a comparison for each iteration.

First example (returning 1):

.L4:
    call    x
    testl   %eax, %eax
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

Second example (returning sqrt(7)):

.L4:
    call    x
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jp  .L4
    xorpd   %xmm1, %xmm1
    ucomisd %xmm1, %xmm0
    jne .L4
    movl    $0, %eax
    addq    $32, %rsp
    popq    %rbp
    ret
    .seh_endproc
    .ident  "GCC: (tdm64-2) 4.8.1"

However, at -O1 and above, they both produce the same assembly as the previous examples (an unconditional jmp back to the preceding label).

TL;DR

Under GCC, the different loops are compiled to identical assembly. The compiler evaluates the constant values and doesn't bother performing any actual comparison.

The moral of the story is:

• There exists a layer of translation between C source code and CPU instructions, and this layer has important implications for performance.
• Therefore, performance cannot be evaluated by only looking at source code.
• The compiler should be smart enough to optimize such trivial cases. Programmers should not waste their time thinking about them in the vast majority of cases.

这里有一个问题:如果您实际编写一个程序并测量它的速度，两个循环的速度可能是不同的!以下是一些合理的比较:

unsigned long i = 0;
while (1) { if (++i == 1000000000) break; }

unsigned long i = 0;
while (2) { if (++i == 1000000000) break; }

添加了一些打印时间的代码后，一些随机的效果(比如循环在一条或两条缓存线中的位置)可能会产生影响。一个循环可能完全位于一条缓存线内，或者位于一条缓存线的开头，或者它可能横跨两条缓存线。因此，面试官说最快的可能真的是最快的——纯属巧合。

最坏的情况:优化编译器不知道循环做了什么，但知道执行第二个循环时产生的值与第一个循环产生的值相同。并为第一个循环生成完整代码，但不为第二个循环生成完整代码。

我曾经用C语言和汇编代码编写程序，那时候这类废话可能会有很大不同。当它确实起作用时，我们在汇编中写了出来。

如果我被问到这个问题，我会重复唐纳德·克努特1974年关于过早优化的名言，如果面试官没有笑，我就会走开，然后继续前进。

在我看来，这是一个被伪装成技术问题的行为面试问题。有些公司会这样做——他们会问一个任何有能力的程序员都应该很容易回答的技术问题，但是当面试者给出正确答案时，面试官会告诉他们他们错了。

公司想看看你在这种情况下会作何反应。你是否会因为自我怀疑或害怕让面试官不高兴而安静地坐在那里，不强调自己的答案是正确的?或者你愿意挑战一个你知道是错误的权威人士吗?他们想看看你是否愿意坚持自己的信念，以及你是否能以一种机智和尊重的方式做到这一点。