Czy „for (;;)” jest szybsze niż „while (TRUE)”? Jeśli nie, dlaczego ludzie go używają?

for (;;) {
    //Something to be done repeatedly
}

Często widziałem takie rzeczy, ale myślę, że jest to raczej dziwne… Czy nie byłoby o wiele jaśniej powiedzieć while(true), czy coś w tym stylu?

Zgaduję, że (co jest powodem, dla którego wielu programistów ucieka się do tajemniczego kodu) jest to niewielki margines szybciej?

Dlaczego i czy naprawdę warto? Jeśli tak, dlaczego nie zdefiniować tego w ten sposób:

#define while(true) for(;;)

Zobacz także: Co jest szybsze: while (1) czy while (2)?

1. To nie jest szybsze.
2. Jeśli naprawdę ci zależy, skompiluj z wyjściem asemblera dla swojej platformy i zobacz.
3. To nie ma znaczenia. To nigdy się nie liczy. Napisz swoje nieskończone pętle, jak chcesz.

wolę for(;;) z dwóch powodów.

Po pierwsze, niektóre kompilatory wyświetlają ostrzeżenia dotyczące while(true) (coś w rodzaju „warunek pętli jest stały”). Unikanie ostrzeżeń jest zawsze dobrą rzeczą.

Po drugie, myślę, że for(;;)jest jaśniejszy i bardziej wymowny. Chcę nieskończonej pętli. To dosłownie ma ma warunku, nie zależy od niczego. Chcę tylko, żeby trwało to wiecznie, dopóki nie zrobię czegoś, aby się z tego wyrwać.

Podczas gdy z while(true) cóż, co ma wspólnego z czymkolwiek? Nie interesuje mnie pętla, dopóki prawda nie stanie się fałszem, co dosłownie mówi ta forma (pętla, gdy prawda jest prawdziwa). Chcę tylko zapętlić.

I nie, nie ma absolutnie żadnej różnicy w wydajności.

Osobiście używam, for (;;)ponieważ nie ma w nim żadnych liczb, to tylko słowo kluczowe. Wolę go while (true), while (1), while (42), while (!0)etc etc.

Z powodu Dennisa Ritchiego

• Zacząłem używać, for (;;)ponieważ tak robi to Dennis Ritchie w K&R, a ucząc się nowego języka, zawsze staram się naśladować sprytnych facetów.

• To jest idiomatyczne C / C ++. Prawdopodobnie lepiej na dłuższą metę przyzwyczaić się do tego, jeśli planujesz dużo robić w przestrzeni C / C ++.

• Twój #definenie zadziała, ponieważ rzecz # define'd musi wyglądać jak identyfikator C.

• Wszystkie nowoczesne kompilatory będą generować ten sam kod dla obu konstrukcji.

Z pewnością nie jest szybszy w żadnym rozsądnym kompilatorze. Obaj zostaną zestawieni w bezwarunkowe skoki. Wersja for jest łatwiejsza do wpisania (jak powiedział Neil) i będzie zrozumiała, jeśli zrozumiesz składnię pętli.

Jeśli jesteście ciekawi, oto co daje mi gcc 4.4.1 dla x86. Oba używają instrukcji x86 JMP .

void while_infinite()
{
    while(1)
    {
    puts("while");
    }
}

void for_infinite()
{
    for(;;)
    {
    puts("for");
    }
}

kompiluje się do (częściowo):

.LC0:
.string "while"
.text
.globl while_infinite
    .type   while_infinite, @function
while_infinite:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $24, %esp
.L2:
    movl    $.LC0, (%esp)
    call    puts
    jmp .L2
    .size   while_infinite, .-while_infinite
    .section    .rodata
.LC1:
    .string "for"
    .text
.globl for_infinite
    .type   for_infinite, @function
for_infinite:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $24, %esp
.L5:
    movl    $.LC1, (%esp)
    call    puts
    jmp .L5
    .size   for_infinite, .-for_infinite

Wolę, for (;;)ponieważ jest najbardziej spójny w różnych językach podobnych do C.

W C ++ while (true)jest w porządku, ale w C musisz zdefiniować nagłówek true, ale TRUEjest to również powszechnie używane makro. Jeśli używasz while (1)go poprawnie w C i C ++ oraz JavaScript, ale nie w Javie lub C #, które wymagają, aby warunek pętli był wartością logiczną, na przykład while (true)lub while (1 == 1). W PHP w słowach kluczowych nie jest rozróżniana wielkość liter, ale język preferuje wielkie litery TRUE.

Jednak for (;;)we wszystkich tych językach jest zawsze całkowicie poprawne.

Osobiście wolę for (;;)idiom (który zostanie skompilowany do tego samego kodu co while (TRUE).

Używanie while (TRUE)może być bardziej czytelne w pewnym sensie, zdecydowałem się użyć for (;;)idiomu, ponieważ się wyróżnia .

Konstrukcja nieskończonej pętli powinna być łatwo zauważalna lub wywoływana w kodzie i osobiście uważam, że for (;;)styl robi to nieco lepiej niż while (TRUE)lub while (1).

Przypominam też, że niektóre kompilatory wyświetlają ostrzeżenia, gdy kontrolujące wyrażenie pętli while jest stałą. Nie wydaje mi się, żeby to się zdarzało zbyt często, ale wystarczy mi możliwość fałszywych ostrzeżeń, abym chciał tego uniknąć.

Widziałem, że niektórzy wolą to, ponieważ mają #define gdzieś w ten sposób:

#define EVER ;;

Co pozwala im napisać to:

for (EVER)
{
    /* blah */
}

A co z (jeśli twój język to obsługuje):

start:
/* BLAH */
goto start;

Nie ma różnicy pod względem generowanego kodu maszynowego.

Jednak, aby przezwyciężyć ten trend, argumentowałbym, że forma while (TRUE) jest znacznie bardziej czytelna i intuicyjna niż for (;;), a czytelność i przejrzystość są znacznie ważniejszymi powodami dla wytycznych kodowania niż jakiekolwiek powody, dla których ja ' słyszałem o podejściu for (;;) (wolę oprzeć moje wytyczne dotyczące kodowania na solidnym uzasadnieniu i / lub dowodzie skuteczności).

Nie tylko dobrze znany wzorzec, ale standardowy idiom w C (i C ++)

while(true)

generuje ostrzeżenie w programie Visual Studio (stan jest stały). Większość miejsc, w których pracowałem, kompiluje kompilacje produkcyjne z ostrzeżeniami jako błędami. Więc

for(;;)

jest preferowany.

Oba powinny być takie same, jeśli kod jest zoptymalizowany przez kompilator. Aby wyjaśnić, co rozumiem przez optymalizację, oto przykładowy kod napisany w MSVC 10:

int x = 0;

while(true) // for(;;)
{
    x +=1;

    printf("%d", x);
}

Jeśli zbudujesz go w trybie debugowania ( bez żadnej optymalizacji (/ Od) ), demontaż pokazuje wyraźną różnicę. Istnieją dodatkowe instrukcje dotyczące truestanu wewnątrz while.

while(true)
00D313A5  mov         eax,1                //extra 
00D313AA  test        eax,eax              //extra
00D313AC  je          main+39h (0D313B9h)  //extra
    {
        x +=1;
00D313AE  mov         eax,dword ptr [x]  
00D313B1  add         eax,1  
00D313B4  mov         dword ptr [x],eax  
    printf("%d", x);
    ...
    }
00D313B7  jmp         main+25h (0D313A5h)  


for(;;)
    {
        x +=1;
00D213A5  mov         eax,dword ptr [x]  
00D213A8  add         eax,1  
00D213AB  mov         dword ptr [x],eax  
    printf("%d", x);
    ...
    }
00D213AE  jmp         main+25h (0D213A5h)  

Jeśli jednak zbudujesz swój kod w trybie wydania (z domyślną maksymalną prędkością (/ O2) ), otrzymasz te same dane wyjściowe dla obu. Obie pętle są zredukowane do jednej instrukcji skoku.

for(;;)
    {
        x +=1;
01291010  inc         esi  

        printf("%d", x);
    ...
    }
0129101C  jmp         main+10h (1291010h)  

    while(true)
    {
        x +=1;
00311010  inc         esi  

        printf("%d", x);
    ...
    }
0031101C  jmp         main+10h (311010h)  

Niezależnie od tego, którego użyjesz, nie ma znaczenia, ponieważ przyzwoity kompilator z optymalizacją prędkości jest włączony.

To kwestia osobistych preferencji, który sposób jest szybszy. Osobiście jestem typem dotykowym i nigdy nie patrzę na klawiaturę, podczas programowania - potrafię wpisywać dotykowo wszystkie 104 klawisze na swojej klawiaturze.

Uważam, że szybciej wpisuję „while (TRUE)”.

Dodałem w myślach kilka pomiarów ruchu palca i zsumowałem je. „for (;;)” ma około 12 szerokości klawiszy ruchów do tyłu i do czwartego (między klawiszami home a klawiszami oraz między klawiszami home a klawiszem SHIFT), natomiast (TRUE) ma około 14 szerokości klawiszy ruchów wstecz i czwarty.

Jednak podczas pisania tego drugiego jestem znacznie mniej podatny na błędy. Myślę mentalnie słowami naraz, więc szybciej wpisuję rzeczy takie jak „nIndex” niż akronimy takie jak „nIdx”, ponieważ muszę w myślach przeliterować litery, zamiast wypowiadać je w myślach i pozwalać palcom na automatyczne pisanie -wpisz słowo (jak jazda na rowerze)

(Mój test porównawczy TypingTest.com = 136 WPM)

Wszystkie dobre odpowiedzi - zachowanie powinno być dokładnie takie samo.

JEDNAK - tylko przypuśćmy, że ZROBIŁO różnicę. Załóżmy, że jeden z nich otrzymał 3 dodatkowe instrukcje na iterację.

Czy powinno cię to obchodzić?

TYLKO jeśli to, co robisz wewnątrz pętli, jest prawie niczym , co prawie nigdy nie ma miejsca.

Chodzi mi o to, że jest mikro-optymalizacja i makro-optymalizacja. Mikro-optymalizacja jest jak „strzyżenie, aby schudnąć”.

Nie wyobrażam sobie, żeby wartościowy kompilator wygenerował inny kod. Nawet gdyby tak było, nie byłoby możliwości określenia, bez przetestowania konkretnego kompilatora, który jest bardziej wydajny.

Jednak sugeruję, abyś wolał for(;;)z następujących powodów:

• kilka kompilatorów, których użyłem, wygeneruje stałe ostrzeżenie o wyrażeniu while (true) z odpowiednimi ustawieniami poziomu ostrzeżenia.

• w twoim przykładzie makro TRUE może nie być zdefiniowane zgodnie z oczekiwaniami

• istnieje wiele możliwych wariantów w nieskończonej pętli while takie jak while(1), while(true), while(1==1)itp .; więc for(;;)prawdopodobnie spowoduje większą spójność.

for(;;Sleep(50))
{
    // Lots of code
}

Jest jaśniejsze niż:

while(true)
{
    // Lots of code
    Sleep(50);
}

Nie dotyczy to sytuacji, gdy nie używasz Sleep().

Pętla „na zawsze” jest popularna w systemach wbudowanych jako pętla w tle. Niektórzy implementują to jako:

for (; ;)
{
 // Stuff done in background loop
}

Czasami jest to realizowane jako:

while (TRUE /* or use 1 */)
{
 // Stuff done in background loop
}

A jeszcze inna implementacja to:

do
{
 // Stuff done in background loop
} while (1 /* or TRUE */);

Kompilator optymalizujący powinien generować taki sam lub podobny kod asemblera dla tych fragmentów. Jedna ważna uwaga: czas wykonywania pętli nie jest dużym problemem, ponieważ te pętle trwają w nieskończoność, a sekcja przetwarzania zajmuje więcej czasu.

Zakładam, że (true) jest bardziej czytelne niż for (;;) - wygląda na to, że programista przeoczył coś w pętli for :)

Najważniejszym powodem używania „for (;;)” jest obawa przed używaniem „while (TRUE)” podczas programowania eksploracyjnego. Łatwiej jest kontrolować liczbę powtórzeń za pomocą „for”, a także łatwiej jest przekształcić pętlę „for” w nieskończoną.

Na przykład, jeśli konstruujesz funkcję rekurencyjną, możesz ograniczyć liczbę wywołań tej funkcji przed konwersją na nieskończoną pętlę.

    for(int i=0;i<1000;i++) recursiveFunction(oneParam);

Kiedy jestem pewien swojej funkcji, konwertuję ją na nieskończoną pętlę:

    for(;;) recursiveFunction(oneParam);