Bucla fără sfârșit în C/C++ [închis] (Programare, C++, C, Bucle, Buclă Infinită)

magu_ a intrebat.
a intrebat.

Există mai multe posibilități de a face o buclă nesfârșită, iată câteva pe care le-aș alege:

  • for(;;) {}
  • while(1) {} / while(true) {}
  • do {} while(1) / do {} while(true)

Există o anumită formă pe care ar trebui să o aleg? Și compilatoarele moderne fac diferența între mijlocul și ultima instrucțiune sau își dă seama că este o buclă nesfârșită și sare complet peste partea de verificare?

Edit: cum a fost menționat, am uitat goto, dar acest lucru a fost făcut din motivul că nu îmi place deloc ca și comandă.

Edit2: Am făcut niște grep pe ultimele versiuni luate de pe kernel.org. I does pare că nu s-a schimbat mare lucru în timp (în cadrul Kernel-ului cel puțin)

Comentarii

    31

  • Cred că ai uitat endless: GOTO endless; –  > Por Alexander.
  • Cred că ar trebui să alegi opțiunea care face codul suficient de lizibil, cum ar fi while (true) {} –  > Por Abhishek Bansal.
  • Ați uitat posibilitatea GOTO. –  > Por kevinji.
  • Acest lucru a fost deja întrebat aici: stackoverflow.com/questions/224138/infinite-loops-top-or-bottom – user1508519
  • @shcherbak. Am adăugat un grafic despre asta. Pentru oricine este, de asemenea, interesat de ea. –  > Por magu_.
12 răspunsuri
Lundin

Problema cu această întrebare este că vei primi foarte multe răspunsuri subiective care spun pur și simplu „eu prefer asta…”. În loc să fac astfel de afirmații inutile, voi încerca să răspund la această întrebare cu fapte și referințe, mai degrabă decât cu opinii personale.

Prin experiență, putem probabil să începem prin a exclude alternativele do-while (și goto), deoarece nu sunt utilizate în mod obișnuit. Nu-mi amintesc să le fi văzut vreodată în cod de producție live, scris de profesioniști.

while(1), while(true) și for(;;) sunt cele 3 versiuni diferite care există în mod obișnuit în codul real. Ele sunt, bineînțeles, complet echivalente și rezultă în același cod mașină.


for(;;)

  • Acesta este exemplul original, canonic, al unei bucle eterne. În vechea biblie C Limbajul de programare C de Kernighan și Ritchie, putem citi că:

    K&R 2nd ed 3.5:

    for (;;) {
    ...
    }
    

    este o buclă „infinită”, despre care se presupune că trebuie întreruptă prin alte mijloace, cum ar fi un break sau un return. Utilizarea while sau for este în mare măsură o chestiune de preferințe personale.

    Pentru o lungă perioadă de timp (dar nu pentru totdeauna), această carte a fost considerată drept canon și însăși definiția limbajului C. De când K&R a decis să arate un exemplu de for(;;), aceasta ar fi fost considerată cea mai corectă formă, cel puțin până la standardizarea C din 1990.

    Cu toate acestea, K&R însuși declarase deja că a fost o chestiune de preferință.

    Iar astăzi, K&R este o sursă foarte discutabilă pentru a fi folosită ca referință canonică pentru C. Nu numai că este depășită de mai multe ori (nu abordează nici C99, nici C11), dar predică și practici de programare care sunt adesea considerate proaste sau vădit periculoase în programarea C modernă.

    Dar, în ciuda faptului că K&R este o sursă discutabilă, acest aspect istoric pare să fie cel mai puternic argument în favoarea for(;;).

  • Argumentul împotriva for(;;) loop este acela că este oarecum obscur și ilizibil. Pentru a înțelege ce face codul, trebuie să cunoașteți următoarea regulă din standard:

    ISO 9899:2011 6.8.5.3:

    for ( clause-1 ; expression-2 ; expression-3 ) statement
    

    /–/

    Atât clauza-1, cât și expresia-3 pot fi omise. O expresie-2 omisă este înlocuită cu o constantă diferită de zero.

    Pe baza acestui text din standard, cred că cei mai mulți vor fi de acord că nu este doar obscur, ci și subtil, deoarece prima și a treia parte a buclei for sunt tratate diferit de a doua, atunci când sunt omise.


while(1)

  • Se presupune că aceasta este o formă mai ușor de citit decât for(;;). Cu toate acestea, se bazează pe o altă regulă obscură, deși bine cunoscută, și anume că C tratează toate expresiile care nu sunt egale cu zero ca fiind boolean logic true. Fiecare programator C este conștient de acest lucru, deci nu este probabil să fie o problemă majoră.

  • Există o mare problemă practică cu această formă, și anume că compilatoarele tind să dea un avertisment pentru aceasta: „condiția este întotdeauna adevărată” sau similar. Acesta este un avertisment bun, de un tip pe care chiar nu doriți să îl dezactivați, deoarece este util pentru a găsi diverse erori. De exemplu, o eroare de genul while(i = 1), când programatorul a intenționat să scrie while(i == 1).

    De asemenea, este probabil ca analizatorii de cod static externi să se plângă de „condiția este întotdeauna adevărată”.


while(true)

  • Pentru a face while(1) și mai ușor de citit, unii folosesc while(true) în schimb. Consensul în rândul programatorilor pare să fie că aceasta este cea mai ușor de citit formă.

  • Cu toate acestea, această formă are aceeași problemă ca și while(1), așa cum a fost descrisă mai sus: avertismente de tipul „condiția este întotdeauna adevărată”.

  • Când vine vorba de C, această formă are un alt dezavantaj, și anume că folosește macroul true din stdbool.h. Deci, pentru ca acest lucru să se compileze, trebuie să includem un fișier antet, ceea ce poate fi sau nu incomod. În C++ acest lucru nu reprezintă o problemă, deoarece bool există ca un tip de date primitiv și true este un cuvânt cheie al limbajului.

  • Un alt dezavantaj al acestei forme este că folosește tipul bool din C99, care este disponibil doar pe compilatoarele moderne și nu este compatibil cu trecutul. Din nou, aceasta este o problemă doar în C și nu în C++.


Deci, ce formă să folosiți? Niciuna nu pare perfectă. Este, așa cum K&R spunea deja în Evul Mediu, o chestiune de preferințe personale.

Personal, eu folosesc întotdeauna for(;;) doar pentru a evita avertismentele compilatorului/analistului generate frecvent de celelalte forme. Dar poate mai important din această cauză:

Dacă chiar și un începător în C cunoaștefor(;;) înseamnă o buclă eternă, atunci pentru cine încercați să faceți codul mai ușor de citit?

Cred că la asta se rezumă totul. Dacă încerci să-ți faci codul sursă mai ușor de citit pentru neprogramatori, care nu cunosc nici măcar părțile fundamentale ale limbajului de programare, atunci nu faci decât să pierzi timpul. Ei nu ar trebui să vă citească codul.

Și din moment ce toți cei care ar trebui să ar trebui să vă citească codul știe deja ce for(;;) înseamnă, nu are rost să îl faceți mai ușor de citit – este deja cât se poate de ușor de citit.

Comentarii

  • Textul dvs. în bold este chiar adevărul. –  > Por peterh – Reinstaurați-o pe Monica.
  • @Lundin: Mi se pare înșelătoare această replică >> În loc să faceți astfel de afirmații inutile, voi încerca să răspund la această întrebare cu fapte și referințe, în loc de opinii personale.”………. pentru că la final toate punctele pe care le-ai scris sunt „opinii personale” ale lui XYZ. Dacă alte răspunsuri ți se par „afirmații inutile”, atunci nu găsesc nimic în răspunsul tău, care să fie diferit de celelalte! –  > Por Nawaz.
  • @Nawaz „Opinia personală” a grupului de lucru 14 al comitetului de standardizare ISO? 🙂 Observația viza în principal pe cei care vor scrie „Folosiți for(;;;) pentru că sunt random_dude_999 pe stack overflow și așa spun eu”. Ultima parte a răspunsului meu conține opinii personale, dar am etichetat explicit ca atare. Majoritatea celorlalte conținuturi pot fi fie citate din standard, fie sunt afirmații „de facto” învățate din experiență. De exemplu, orice programator veteran de C poate garanta că do-while(1) nu este folosit în codul real, dar devine greu de găsit o sursă pe care să o citezi pentru acest lucru. –  > Por Lundin.
  • @Lundin Ceea ce vreau să spun, care este relevant pentru întrebare și mai ales pentru răspunsul tău, este că conceptul de bună practică de programare este mult mai vechi, iar realizarea sa este mult mai subiectivă, decât pari să crezi tu. Nu e nevoie de un salt de imaginație pentru a vedea că, dacă ceea ce acum 30 de ani era considerat sunet acum este considerat rău, atunci peste alți 30 de ani ceea ce acum este considerat sunet …. –  > Por JulianSymes.
  • Ca cineva care era deja programator când a apărut cartea lui K+R, sunt în deplin acord cu @user1681572. În afară de chestiunile OO, toate elementele majore a ceea ce este considerat „bune practici moderne de programare” de astăzi, existau deja și erau deja adoptate pe scară largă. Doar că K+R nu a fost de acord cu ele și, ca efect secundar, a sfârșit prin a crea o întreagă subcultură de programare dominantă, care va avea nevoie de zeci de ani pentru a reveni la ceea ce era deja cunoscut în anii ’70. –  > Por RBarryYoung.
Nawaz

Este foarte subiectiv. Eu scriu asta:

while(true) {} //in C++

Pentru că intenția sa este foarte clară și este, de asemenea, ușor de citit: te uiți la ea și te știi că se intenționează o buclă infinită.

S-ar putea spune for(;;) este, de asemenea, clară. Dar eu aș spune că, din cauza sintaxa alambicată, această opțiune necesită cunoștințe suplimentare pentru a ajunge la concluzia că este o buclă infinită, prin urmare este relativ mai puțin clară. Aș spune chiar că există mai multe număr de programatori care nu știu ce înseamnă for(;;) face (chiar dacă știu că de obicei for bucla), dar aproape toți programatorii care știu while buclă și-ar da seama imediat ce while(true) face.

Pentru mine, scrierea for(;;) pentru a însemna buclă infinită, este ca și cum ai scrie while() pentru a însemna buclă infinită – în timp ce prima funcționează, a doua NU. În primul caz, gol condiția se dovedește a fi true implicit, dar în cel de-al doilea caz, este o eroare! I personal nu mi-a plăcut acest lucru.

Acum while(1) există și în concurs. Eu aș întreba: de ce while(1)? De ce nu while(2), while(3) sau while(0.1)? Ei bine, orice ai scrie, vrei să spui de fapt while(true) – dacă este așa, atunci de ce nu o scrieți în loc?

În C (dacă voi scrie vreodată), probabil că aș scrie așa:

while(1) {} //in C

While while(2), while(3) și while(0.1) ar avea la fel de mult sens. Dar, pentru a fi conform cu ceilalți programatori C, aș scrie while(1), deoarece mulți programatori C scriu așa și nu găsesc niciun motiv să mă abat de la normă.

Comentarii

  • for(;;;) este foarte clar, încă nu am întâlnit un alt programator (cu experiență) care să nu știe că seamănă cu o buclă infinită. În plus, este mai puțin caractere de scris. –  > Por miguel.martin.
  • @miguel.martin Dar include o față de plâns. –  > Por Maroun.
  • @Maroun Bucla se termină atunci când lacrimile se opresc. – user1508519
  • @miguel.martin: Ar trebui să recitiți din nou comentariul, ca să știți de ce for(;;) este comparativ mai puțin clar >> „for(;;;) este foarte clar, încă nu am întâlnit un alt (experimentat) programator care să nu știe că seamănă cu o buclă infinită.” (sublinierea îmi aparține). De ce ați simțiți nevoia de a scrie „(experimentat)” în comentariul dumneavoastră? Scrieți cod doar pentru experimentați programatori experimentați? –  > Por Nawaz.
  • @Nawaz mai ales din două motive, în primul rând, mai puține taste, în al doilea rând, logic, unul nu înseamnă adevărat în mod normal. Deci, lizibilitate. –  > Por magu_.
Pita

Într-un act suprem de plictiseală, am scris de fapt câteva versiuni ale acestor bucle și le-am compilat cu GCC pe mac mini.

while(1){} și for(;;) {}au produs aceleași rezultate de asamblare, în timp ce do{} while(1); a produs un cod de asamblare similar, dar diferit

iată-l pe cel pentru bucla while/for

    .section    __TEXT,__text,regular,pure_instructions
    .globl  _main
    .align  4, 0x90
_main:                                  ## @main
    .cfi_startproc
## BB#0:
    pushq   %rbp
Ltmp2:
    .cfi_def_cfa_offset 16
Ltmp3:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
Ltmp4:
    .cfi_def_cfa_register %rbp
    movl    $0, -4(%rbp)
LBB0_1:                                 ## =>This Inner Loop Header: Depth=1
    jmp LBB0_1
    .cfi_endproc

și bucla do while

        .section    __TEXT,__text,regular,pure_instructions
    .globl  _main
    .align  4, 0x90
_main:                                  ## @main
    .cfi_startproc
## BB#0:
    pushq   %rbp
Ltmp2:
    .cfi_def_cfa_offset 16
Ltmp3:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
Ltmp4:
    .cfi_def_cfa_register %rbp
    movl    $0, -4(%rbp)
LBB0_1:                                 ## =>This Inner Loop Header: Depth=1
    jmp LBB0_2
LBB0_2:                                 ##   in Loop: Header=BB0_1 Depth=1
    movb    $1, %al
    testb   $1, %al
    jne LBB0_1
    jmp LBB0_3
LBB0_3:
    movl    $0, %eax
    popq    %rbp
    ret
    .cfi_endproc

Comentarii

  • +1 pentru efortul de a cerceta efectiv codul de asamblare –  > Por utilizator.
  • Pe linux, am făcut gcc -S -o test1.asm testing.cpp cu cele trei bucle diferite în fișiere separate și am făcut cmp test1.asm test2.asm, etc. Se pare că nu există nicio diferență. – user1508519
  • +1 plictiseala creează chestii utile 🙂 –  > Por RobAu.
  • din păcate, nu sunt suficient de familiarizat cu asamblarea pentru a ști ce înseamnă toate astea. și @remyabel versiunea mea gcc este versiunea este Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix din curiozitate, v-ar deranja să împărtășiți versiunea dvs. de gcc –  > Por Pita.
  • @user1216838 Vezi răspunsul meu. – user1508519
user1508519

Toată lumea pare să îi placă while (true):

https://stackoverflow.com/a/224142/1508519

https://stackoverflow.com/a/1401169/1508519

https://stackoverflow.com/a/1401165/1508519

https://stackoverflow.com/a/1401164/1508519

https://stackoverflow.com/a/1401176/1508519

Conform SLaks, acestea se compilează identic.

Ben Zotto spune, de asemenea, că nu contează:

Nu este mai rapid. Dacă vă pasă cu adevărat, compilați cu ieșirea asamblatorului pentru platforma dvs. și uitați-vă să vedeți. Nu contează. Acest lucru nu contează niciodată. Scrieți-vă buclele infinite cum doriți.

Ca răspuns la user1216838, iată încercarea mea de a reproduce rezultatele sale.

Aici este mașina mea:

cat /etc/*-release
CentOS release 6.4 (Final)

versiunea gcc:

Target: x86_64-unknown-linux-gnu
Thread model: posix
gcc version 4.8.2 (GCC)

Și fișierele de test:

// testing.cpp
#include <iostream>

int main() {
    do { break; } while(1);
}

// testing2.cpp
#include <iostream>

int main() {
    while(1) { break; }
}

// testing3.cpp
#include <iostream>

int main() {
    while(true) { break; }
}

Comenzile:

gcc -S -o test1.asm testing.cpp
gcc -S -o test2.asm testing2.cpp
gcc -S -o test3.asm testing3.cpp

cmp test1.asm test2.asm

Singura diferență este prima linie, aka numele fișierului.

test1.asm test2.asm differ: byte 16, line 1

Ieșire:

        .file   "testing2.cpp"
        .local  _ZStL8__ioinit
        .comm   _ZStL8__ioinit,1,1
        .text
        .globl  main
        .type   main, @function
main:
.LFB969:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        nop
        movl    $0, %eax
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE969:
        .size   main, .-main
        .type   _Z41__static_initialization_and_destruction_0ii, @function
_Z41__static_initialization_and_destruction_0ii:
.LFB970:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        subq    $16, %rsp
        movl    %edi, -4(%rbp)
        movl    %esi, -8(%rbp)
        cmpl    $1, -4(%rbp)
        jne     .L3
        cmpl    $65535, -8(%rbp)
        jne     .L3
        movl    $_ZStL8__ioinit, %edi
        call    _ZNSt8ios_base4InitC1Ev
        movl    $__dso_handle, %edx
        movl    $_ZStL8__ioinit, %esi
        movl    $_ZNSt8ios_base4InitD1Ev, %edi
        call    __cxa_atexit
.L3:
        leave
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE970:
        .size   _Z41__static_initialization_and_destruction_0ii, .-_Z41__static_initialization_and_destruction_0ii
        .type   _GLOBAL__sub_I_main, @function
_GLOBAL__sub_I_main:
.LFB971:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        movl    $65535, %esi
        movl    $1, %edi
        call    _Z41__static_initialization_and_destruction_0ii
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
.LFE971:
        .size   _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main
        .section        .ctors,"aw",@progbits
        .align 8
        .quad   _GLOBAL__sub_I_main
        .hidden __dso_handle
        .ident  "GCC: (GNU) 4.8.2"
        .section        .note.GNU-stack,"",@progbits

Cu -O3, rezultatul este considerabil mai mic, desigur, dar tot nu există nicio diferență.

Comentarii

  • Sunt un dezvoltator cu multă experiență și disprețuiesc while (true). –  > Por Kaz.
  • +1 pentru că ai răspuns efectiv la întrebare și ai arătat cum compilatorului nu-i pasă ce folosești. –  > Por Matt J..
Kaz

Idiomul proiectat în limbajul C (și moștenit în C++) pentru bucla infinită este for(;;): omiterea unei forme de testare. La do/while și while nu au această caracteristică specială; expresiile lor de test sunt obligatorii.

for(;;) nu exprimă „buclă în timp ce este adevărată o condiție care se întâmplă să fie întotdeauna adevărată”. Exprimă „buclă la nesfârșit”. Nu este prezentă nicio condiție superfluă.

Prin urmare, expresia for(;;) este construcția canonică buclă fără sfârșit. Acesta este un fapt.

Tot ceea ce rămâne la îndemâna opiniei este dacă să scriem sau nu bucla nesfârșită canonică, sau să alegem ceva baroc care implică identificatori și constante suplimentare, pentru a construi o expresie superfluă.

Chiar dacă expresia de testare a while ar fi fost opțională, ceea ce nu este cazul, while(); ar fi ciudat. while Ce? În schimb, răspunsul la întrebarea for ce? este: de ce, vreodată – pentru totdeauna! Ca o glumă, unii programatori din zilele trecute au definit macro-uri goale, pentru a putea scrie for(ev;e;r);.

while(true) este superioară lui while(1) pentru că cel puțin nu implică kludge-ul că 1 reprezintă adevărul. Cu toate acestea, while(true) nu a intrat în C decât în C99. for(;;) există în toate versiunile de C până la limbajul descris în cartea K&R1 din 1978 și în toate dialectele de C++ și chiar în limbajele înrudite. Dacă codificați într-o bază de cod scrisă în C90, trebuie să vă definiți propriul true pentru while (true).

while(true) citește prost. În timp ce ceea ce este adevărat? Nu prea vrem să vedem identificatorul true în cod, cu excepția cazului în care inițializăm variabile booleene sau le atribuim. true nu trebuie să apară niciodată în testele condiționate. Un bun stil de codare evită astfel de lucruri:

if (condition == true) ...

în favoarea lui:

if (condition) ...

Din acest motiv while (0 == 0) este superior lui while (true): folosește o condiție reală care testează ceva, care se transformă într-o propoziție: „bucla în timp ce zero este egal cu zero.” Avem nevoie de o predicat pentru a merge bine cu „while”; cuvântul „true” nu este un predicat, ci operatorul relațional == este.

Comentarii

  • Nu știu; cred că prefer for(ever;and;ever); eu însumi. Poate că este o chestiune de preferințe personale. :) –  > Por utilizator.
  • #define forever for(;;) –  > Por Michel Billaud.
Aerom Xundes

Eu folosesc for(;/*ever*/;).

Este ușor de citit și durează puțin mai mult să tastez (din cauza deplasărilor pentru asteriscuri), ceea ce indică faptul că ar trebui să fiu foarte atent atunci când folosesc acest tip de buclă. Textul verde care apare în condițional este, de asemenea, o priveliște destul de ciudată – un alt indiciu că această construcție este prost văzută dacă nu este absolut necesară.

Comentarii

  • Sau pur și simplu #define forever while(1). forever { … } –  > Por Dmitry.
  • @Dmitry: Tu ar putea face acest lucru, dar asta ar înfrânge ideea de lizibilitate instantanee. Altcineva care citește codul ar trebui să caute definiția pentru a se asigura că forever este într-adevăr o buclă eternă. Adăugarea /*ever*/ adaugă doar un pic de lizibilitate suplimentară. –  > Por Aerom Xundes.
  • da, este confuz la început, dar are două avantaje. Primul este că, în editorii inteligenți, mouse-ul de pe el arată #define forever while(1), ceea ce ar trebui să fie clar chiar și pentru începători. Al doilea este că, în general, este mai clar în ceea ce privește intenția buclei decât celelalte. Nu cu mult timp în urmă, buclele foreach erau destul de eretice și nu erau evidente la prima vedere, iar acum sunt acceptate ca standard. Deși, personal, aș prefera „repeat” în locul lui „forever”, deoarece bucla nu se derulează de fapt la nesfârșit, deoarece poate fi întreruptă. Pentru a fi corect, începătorii vor vedea while(1) la fel de confuz ca și repeat {}, dacă nu chiar mai mult. –  > Por Dmitry.
  • Deși îmi place „#define repeat for (;/*ever*/;);)”, pierderea evidențierii standard a sintaxei nu merită probabil macroul și, prin urmare, prefer versiunea originală. Păcat că limbajul însuși nu va adopta „repeat/forever {” – –  > Por Neil McGill.
Chris Chambers

Probabil că se compilează în aproape același cod mașină, deci este o chestiune de gust.

Personal, aș alege-o pe cea care este cea mai clară (adică este foarte clar că ar trebui să fie o buclă infinită).

Eu aș opta pentru while(true){}.

Thomas Padron-McCarthy

Eu aș recomanda while (1) { } sau while (true) { }. Este ceea ce ar scrie majoritatea programatorilor și, din motive de lizibilitate, ar trebui să urmați idiomurile comune.

(Ok, deci este nevoie de o „citare evidentă” pentru afirmația despre majoritatea programatorilor. Dar din codul pe care l-am văzut, în C din 1984, cred că este adevărat).

Orice compilator rezonabil le-ar compila pe toate în același cod, cu un salt necondiționat, dar nu m-ar surprinde dacă ar exista unele nerezonabile compilatoare nerezonabile, pentru sisteme integrate sau alte sisteme specializate.

haccks

Există o anumită formă pe care ar trebui să o alegem?

Se poate alege oricare dintre ele. Este o chestiune de alegere. Toate sunt echivalente. while(1) {}/while(true){} este folosit frecvent de programatori pentru bucla infinită.

Comentarii

  • @Dowvoters; Vreți să explicați. –  > Por haccks.
RichardPlunkett

Ei bine, există o mulțime de gusturi în acest caz. Cred că persoanele care provin din mediul C sunt mai predispuse să prefere for(;;;), care se citește ca „forever”. Dacă este pentru muncă, faceți ceea ce fac localnicii, dacă este pentru voi înșivă, faceți-o pe cea pe care o puteți citi cel mai ușor.

Dar, din experiența mea, do { } while (1); nu este aproape niciodată folosit.

user2956373

Toate vor îndeplini aceeași funcție și este adevărat să alegeți ceea ce preferați…aș putea crede că „while(1) sau while(true)” este o practică bună de utilizat.

Comentarii

  • -1: Acest răspuns nu are nimic semnificativ pentru întrebare. –  > Por bwDraco.
SliceSort

Sunt identice. Dar eu sugerez „while(ture)”, care are cea mai bună reprezentare.

Comentarii

  • -1: Acest răspuns nu are nimic semnificativ pentru întrebare. –  > Por bwDraco.
  • ture?? Asta nu va compila! –  > Por Spikatrix.