而(1)和(; ;)有速度差吗？

根据标准没有区别。6.5.3/1有:

For 声明

for ( for-init-statement ; conditionopt ; expressionopt ) statement

相当于

{
for-init-statement
while ( condition ) {
statement
expression ;
}
}

6.5.3/2有:

条件和表达式中的一个或两个都可以省略。缺少条件使隐含的 while 子句等效于 while (true)。

所以根据 C + + 标准的代码:

for (;;);

完全一样:

{
while (true) {
;
;
}
}

我认为两者在性能方面是一样的。但是我更喜欢 while (1)的可读性，但是我想知道为什么需要一个无限循环。

while(1)是大多数编译器都能识别的 for(;;)的惯用语。

我很高兴看到 perl 也能识别 until(0)。

来自 Stroustrup，TC + + PL (第三版) ，6.1.1:

奇怪的符号 for (;;)是指定无限循环的标准方法; 您可以将其发音为“ forever”。while (true)是另一种选择。

我更喜欢 for (;;)。

理论上，一个简单的 彻底的编译器可以在二进制文件中存储文字“1”(浪费空间) ，并检查每次迭代(浪费时间和更多空间)是否1 = = 0。

然而，在现实中，即使“没有”优化，编译器仍然会将两者减少到相同的程度。它们还可能发出警告，因为它可能指示逻辑错误。例如，while的参数可以在其他地方定义，而您没有意识到它是常数。

我感到惊讶的是，没有人提供更直接的形式，对应于所需的集合:

forever:
do stuff;
goto forever;

我听说过一次。

它来自一个 AMD 组装程序员。他指出，C 程序员(人们)没有意识到他们的代码效率低下。他今天说，虽然，gcc 编译器是非常好的，并把像他这样的人的业务。他举例说，并告诉我关于 while 1对 for(;;)。我现在出于习惯使用它，但是 gcc，尤其是解释器，这两天将执行相同的操作(处理器跳转) ，因为它们已经被优化了。

我很惊讶没有人在 perl 中正确地测试 for (;;)和 while (1)！

由于 perl 是直译语言的，运行 perl 脚本的时间不仅包括执行阶段(在本例中是相同的) ，还包括执行前的解释阶段。在进行速度比较时，必须考虑到这两个阶段。

幸运的是，perl 有一个方便的 基准模块，我们可以使用它来实现如下基准测试:

#!/usr/bin/perl -w


use Benchmark qw( cmpthese );


sub t_for   { eval 'die; for (;;) { }'; }
sub t_for2  { eval 'die; for (;;)  { }'; }
sub t_while { eval 'die; while (1) { }'; }


cmpthese(-60, { for => \&t_for, for2 => \&t_for2, while => \&t_while });

注意，我正在测试两个不同版本的无限 for 循环: 一个比 while 循环短，另一个有一个额外的空间使其与 while 循环长度相同。

在 Ubuntu 11.04 x86 _ 64和 perl 5.10.1上，我得到了以下结果:

Rate   for  for2 while
for   100588/s    --   -0%   -2%
for2  100937/s    0%    --   -1%
while 102147/s    2%    1%    --

While 循环显然是这个平台上的赢家。

在 FreeBSD 8.2 x86 _ 64和 perl 5.14.1上:

Rate   for  for2 while
for   53453/s    --   -0%   -2%
for2  53552/s    0%    --   -2%
while 54564/s    2%    2%    --

而 loop 在这里也是赢家。

在 FreeBSD 8.2 i386和 perl 5.14.1上:

Rate while   for  for2
while 24311/s    --   -1%   -1%
for   24481/s    1%    --   -1%
for2  24637/s    1%    1%    --

令人惊讶的是，带有额外空间的 for 循环是这里最快的选择！

我的结论是，如果程序员正在优化速度，那么 while 循环应该在 x86 _ 64平台上使用。显然，在优化空间时应该使用 for 循环。不幸的是，我的结果对于其他平台来说是不确定的。

如果编译器不做任何优化，for(;;)总是比 while(true)快。这是因为 while 语句每次都计算条件，但 for 语句是无条件跳转。但是如果编译器对控制流进行优化，可能会生成一些操作码。您可以非常容易地读取反汇编代码。

另外，你可以这样写一个无限循环:

#define EVER ;;
//...
for (EVER) {
//...
}

Turbo C 与这个老编译器 for(;;)结果在更快的代码比 while(1)。

如今，gcc、 Visual C (我认为几乎所有)编译器都能很好地进行优化，并且很少使用4.7 MHz 的 CPU。

在那些日子里，for( i=10; i; i-- )比 for( i=1; i <=10; i++ )快，因为比较 i是0，结果是 CPU-Zero-Flag 条件跳转。最后用最后一个递减操作 ( i-- )对 Zero-Flag 进行了修改，不需要额外的 cmp 操作。

    call    __printf_chk
decl    %ebx          %ebx=iterator i
jnz     .L2
movl    -4(%ebp), %ebx
leave

这里是带有额外 cmpl 的 for(i=1; i<=10; i++):

    call    __printf_chk
incl    %ebx
cmpl    $11, %ebx
jne     .L2
movl    -4(%ebp), %ebx
leave

总结一下 for (;;)和 while (1)的争论，很明显，前者在老的非优化编译器时代更快，这就是为什么你倾向于在老的代码库中看到它，比如 Lions Unix 源代码注释，但是在牛逼的优化编译器时代，这些收益被优化了，因为后者比前者更容易理解，我相信它会更好。

只是偶然发现了这条线索(尽管已经晚了好几年)。

我想我找到了“ for (; ;)”比“ while (1)”好的实际原因。

根据《2018年条形码标准》

Kernighan & Ritchie long ago recommended for (;;) , which has the additional benefit
of insuring against the visually-confusing defect of a while (l); referencing a variable ‘l’.

基本上，这不是速度问题，而是可读性问题。根据代码的字体/打印，一段时间内数字1(1)可能看起来像小写字母 l。

即1对1(在某些字体中看起来是一样的)。

所以 while (1)可能看起来像依赖于变量字母 L 的 while 循环。

While (true)也可以工作，但是在一些较老的 C 和嵌入式 C 中，除非包含 stdbool.h，否则 true/false 还没有定义。