[C++] Est-ce que "for (;;)" est plus rapide que "while (TRUE)"? Si non, pourquoi les gens l'utilisent-ils?


Answers

Je préfère for(;;) pour deux raisons.

L'un est que certains compilateurs produisent des avertissements sur while(true) (quelque chose comme "condition de boucle est constante"). Éviter les avertissements est toujours une bonne chose à faire.

Un autre est que je pense for(;;) est plus clair et plus révélateur. Je veux une boucle infinie. Il n'a littéralement aucune condition, cela ne dépend de rien. Je veux juste que ça continue pour toujours, jusqu'à ce que je fasse quelque chose pour en sortir.

Alors qu'avec while(true) , eh bien, qu'est-ce qui est vrai avec quoi que ce soit? Je ne suis pas intéressé à boucler jusqu'à ce que true devienne faux, ce que dit littéralement cette forme (loop alors que true est vrai). Je veux juste faire une boucle.

Et non, il n'y a absolument aucune différence de performance.

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

J'ai vu beaucoup de choses de ce genre, mais je pense que c'est plutôt étrange ... Ne serait-il pas plus clair de dire while(true) , ou quelque chose du genre?

Je devine que (c'est la raison pour laquelle beaucoup de programmeurs ont recours au code cryptique) c'est une petite marge plus rapide?

Pourquoi, et vaut-il vraiment la peine? Si oui, pourquoi ne pas le définir de cette façon:

#define while(true) for(;;)

Voir aussi: Quel est le plus rapide: while (1) ou while (2)?




Il n'y a pas de différence en termes de code machine généré.

Cependant, juste pour renverser la tendance, je dirais que la forme while (TRUE) est beaucoup plus lisible et intuitive que pour (;;), et que la lisibilité et la clarté sont des raisons beaucoup plus importantes pour les directives de codage que J'ai entendu parler de l'approche for (;;) (je préfère baser moi-même mes directives de codage sur un raisonnement solide et / ou une preuve d'efficacité).




Je préfère for (;;) parce que c'est le plus cohérent dans différentes langues de type C.

En C ++ while (true) est correct, mais en C, vous dépendez d'un en-tête pour définir true , mais TRUE est aussi une macro couramment utilisée. Si vous utilisez while (1) c'est correct en C et C ++, et JavaScript, mais pas Java ou C #, qui nécessitent que la condition de la boucle soit booléenne, comme while (true) ou while (1 == 1) . En PHP, les mots clés sont insensibles à la casse, mais le langage préfère la valeur TRUE .

Cependant, for (;;) est toujours complètement correct dans toutes ces langues.




La raison la plus importante d'utiliser "for (;;)" est la peur d'utiliser "while (TRUE)" lorsque vous faites une programmation exploratoire. Il est plus facile de contrôler le nombre de répétitions avec "pour", et aussi, plus facile de convertir la boucle "pour" en un infini.

Par exemple, si vous construisez une fonction récursive, vous pouvez limiter la quantité d'appels à la fonction avant de la convertir en boucle infinie.

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

Quand je suis sûr de ma fonction, je la convertis en une boucle infinie:

    for(;;) recursiveFunction(oneParam);



J'ai vu certaines personnes le préférer parce qu'elles ont un #define quelque part comme ceci:

#define EVER ;;

Ce qui leur permet d'écrire ceci:

for (EVER)
{
    /* blah */
}



C'est une question de préférence personnelle qui est plus rapide. Personnellement, je suis un touchtypist et ne regarde jamais mon clavier, pendant la programmation - je peux toucher toutes les 104 touches de mon clavier.

Je trouve si plus rapide de taper "while (TRUE)".

J'ai mentalement ajouté quelques mesures de mouvement du doigt et les ai totalisées. "for (;;)" a environ 12 largeurs de clé de retour et quatrième (entre les touches home et les touches, et entre les touches home et la touche SHIFT) "while (TRUE)" a environ 14 largeurs de clés de retour et Quatrième.

Cependant, je suis beaucoup moins sujet aux erreurs lorsque je tape ce dernier. Je pense mentalement en mots à la fois, donc je trouve plus rapide de taper des choses comme "nIndex" que des acronymes comme "nIdx" parce que je dois épeler mentalement le lettrage plutôt que de le dire dans mon esprit et de laisser mes doigts -type le mot (comme faire du vélo)

(Mon benchmark TypingTest.com = 136 WPM)




while(true)

génère un avertissement avec Visual Studio (la condition est constante). La plupart des endroits où j'ai travaillé compilent des builds de production avec des avertissements comme des erreurs. Alors

for(;;)

est préféré.




La boucle "forever" est populaire dans les systèmes embarqués en tant que boucle d'arrière-plan. Certaines personnes l'implémentent comme:

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

Et parfois, il est implémenté comme:

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

Et encore une autre mise en œuvre est:

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

Un compilateur d'optimisation devrait générer le même code d'assemblage ou similaire pour ces fragments. Une remarque importante: le temps d'exécution des boucles n'est pas un gros problème puisque ces boucles sont éteintes et que plus de temps est consacré à la section de traitement.




À cause de Dennis Ritchie

  • J'ai commencé à utiliser for (;;) parce que c'est comme ça que Dennis Ritchie le fait en K & R, et quand j'apprends une nouvelle langue, j'essaie toujours d'imiter les gars intelligents.

  • C'est idiomatique C / C ++. Il est probablement préférable à long terme de s'y habituer si vous prévoyez de faire beaucoup dans l'espace C / C ++.

  • Votre #define ne fonctionnera pas, puisque la chose étant # define'd doit ressembler à un identifiant C.

  • Tous les compilateurs modernes généreront le même code pour les deux constructions.




Toutes les bonnes réponses - le comportement devrait être exactement le même.

CEPENDANT - Supposez simplement que cela a fait une différence. Supposons que l'un d'eux prenne 3 instructions de plus par itération.

Devriez-vous en prendre soin?

Seulement si ce que vous faites dans la boucle est presque rien , ce qui n'est presque jamais le cas.

Mon point est, il y a la micro-optimisation et la macro-optimisation. La micro-optimisation, c'est comme «se faire couper les cheveux pour perdre du poids».