в то время как (1) против for (;;) Есть ли разница в скорости?

Используя GCC, они оба, похоже, компилируются на один и тот же язык ассемблера:

L2:
        jmp     L2

Там не так много причин предпочесть друг другу. Я думаю, что while(1) и особенно while(true) более читаемы, чем for(;;), но это только мои предпочтения.

В соответствии со стандартом нет никакой разницы. 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).

Итак, согласно стандарту С++, код:

for (;;);

точно такая же, как:

{
  while (true) {
    ;
    ;
  }
}

Компилятор Visual С++, используемый для выдачи предупреждения для

while (1) 

(постоянное выражение), но не для

for (;;)

Я по-прежнему продолжал практиковать предпочтение for (;;), но я не знаю, продолжает ли это компилятор в наши дни.

for(;;) - это один символ меньшего характера, если вы хотите идти в этом направлении, чтобы оптимизировать вещи.

Turbo C с этими старыми компиляторами for(;;) приводит к более быстрому коду, а затем while(1).

Сегодня gcc, Visual C (я думаю, почти все) компиляторы хорошо оптимизируются, а процессоры с частотой 4,7 МГц редко используются.

В те дни for( i=10; i; i-- ) был быстрее, чем for( i=1; i <=10; i++ ), потому что сравнение i равно 0, приводит к условному прыжку с ЦП-нулем. И Zero-Flag был изменен с последней операцией декремента ( i-- ), дополнительная операция cmp не требуется.

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

и здесь с for(i=1; i<=10; i++) с дополнительным cmpl:

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

Для всех людей, которые утверждают, что вы не должны использовать indefinte в то время как циклы, и предлагая глупые вещи, как использование open goto (серьезно, ouch)

while (1) {
     last if( condition1 );
     code();
     more_code(); 
     last if( condition2 ); 
     even_more_code(); 
}

Не может быть реально представлен каким-либо другим способом. Не без создания переменной exit и черной магии, чтобы синхронизировать ее.

Если у вас есть склонность к более синтаксису goto-esque, используйте что-то разумное, которое ограничивает область.

flow: { 

   if ( condition ){ 
      redo flow;
   }
   if ( othercondition ){ 
       redo flow;
   }
   if ( earlyexit ){ 
       last flow;
   }
   something(); # doesn't execute when earlyexit is true 
}

В конечном счете скорость не так важна

Повреждение о том, насколько эффективны быстродействующие различные петлевые конструкции, - это огромная трата времени. Преждевременная оптимизация. Я не могу придумать ни одной ситуации, которую я когда-либо видел, где код профилирования обнаруживал узкие места в моем выборе цикла.

Как правило, это как цикл, так и цикл.

Вы должны "оптимизировать" для удобочитаемости и лаконичности и писать все, что лучше всего, чтобы объяснить проблему следующему бедному присоску, который находит ваш код.

Если вы используете трюк "goto LABEL", который кто-то упомянул, и я должен использовать ваш код, будьте готовы спать одним глазом, особенно если вы делаете это более одного раза, потому что этот материал создает ужасный код спагетти.

Просто потому, что вы можете создать код спагетти, не означает, что вы должны

Если компилятор не делает никакой оптимизации, for(;;) всегда будет быстрее, чем while(true). Это потому, что while-statement оценивает условие каждый раз, но for-statement является безусловным прыжком. Но если компилятор оптимизирует поток управления, он может генерировать некоторые коды операций. Вы можете легко прочитать код разборки.

P.S. вы можете написать бесконечный цикл следующим образом:

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

Из Stroustrup, TС++ PL (3-е издание), §6.1.1:

Любопытная нотация for (;;) - это стандартный способ задания бесконечного цикла; вы можете произнести его "навсегда". [...] while (true) является альтернативой.

Я предпочитаю for (;;).

Я слышал об этом один раз.

Это был сборщик программ AMD. Он заявил, что программисты C (люди) не понимают, что их код имеет неэффективность. Он сказал сегодня, хотя, gcc-компиляторы очень хороши, и вытащили таких людей, как он, из бизнеса. Он сказал, например, и рассказал мне о while 1 vs for(;;). Я использую это сейчас по привычке, но gcc и особенно интерпретаторы будут выполнять ту же операцию (скачок процессора) для обоих этих дней, так как они оптимизированы.

В оптимизированной сборке скомпилированного языка не должно быть заметной разницы между ними. Ни один из них не должен выполнять какие-либо сравнения во время выполнения, они будут просто выполнять код цикла, пока вы не выйдете из цикла вручную (например, с помощью break).

Я удивлен, что никто не тестировал for (;;) по сравнению с while (1) в perl!

Поскольку perl интерпретируемый язык, время запуска perl script состоит не только из фазы выполнения (которая в этом случае является одинаковой), но и для фазы интерпретации перед выполнением. Обе эти фазы должны учитываться при сравнении скорости.

К счастью, perl имеет удобный модуль Benchmark, который мы можем использовать для реализации теста, например следующего:

#!/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 });

Обратите внимание, что я тестирую две разные версии бесконечного цикла: один, который короче цикла 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%    --

Хотя цикл также является победителем здесь.

В 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 (;;) vs while (1), очевидно, что первый был быстрее в дни старых не оптимизирующих компиляторов, поэтому вы, как правило, видите его в более старых базовых кодах, таких как Lions Unix Source code комментарий, однако в эпоху оптимизационных компиляторов badass эти выигрыши оптимизированы, что с тем, что последнее легче понять, чем первое, я считаю, что было бы более предпочтительным.

Я удивлен, что никто не предложил более прямую форму, соответствующую желаемой сборке:

forever:
     do stuff;
     goto forever;

В теории совершенно наивный компилятор мог бы хранить буквальный '1' в двоичном (пустое пространство) и проверять, есть ли 1 == 0 на каждой итерации (теряя время и больше места).

В действительности, однако, даже при оптимизации "нет" компиляторы все равно уменьшат оба значения. Они также могут выдавать предупреждения, поскольку они могут указывать на логическую ошибку. Например, аргумент while может быть определен где-то в другом месте, и вы не понимаете его постоянным.

while(1) - это идиома для for(;;), которая распознается большинством компиляторов.

Я был рад видеть, что perl также распознает until(0).

Я бы подумал, что оба они одинаковы с точки зрения производительности. Но я бы предпочел, чтобы (1) для удобства чтения, но я сомневаюсь, почему вам нужен бесконечный цикл.

Они одинаковы. Есть гораздо более важные вопросы, чтобы обдумать.