Java: for(;;) vs while(true)
Quelle est la différence entre une norme while(true) boucle et for(;;)?
Y en a-t-il, ou les deux seront-ils mappés au même bytecode après la compilation?
9 réponses
Sémantiquement, ils sont complètement équivalents. C'est une question de goût, mais je pense que while(true) semble plus propre, et est plus facile à lire et à comprendre à première vue. En Java, aucun d'entre eux ne provoque d'avertissements du compilateur.
Au niveau du bytecode, il peut dépendre du compilateur et le niveau d'optimisations, mais en principe le code émis doit être le même.
Modifier:
Sur mon compilateur, en utilisant le plugin bytecode Outline , le bytecode pour for(;;){} semble comme ceci:
L0
LINENUMBER 6 L0
FRAME SAME
GOTO L0
Et le bytecode pour while(true){} ressemble à ceci:
L0
LINENUMBER 6 L0
FRAME SAME
GOTO L0
Donc oui, au moins pour moi, ils sont identiques.
C'est à vous de choisir lequel utiliser. Parce qu'ils sont égaux à compilateur.
Créer un fichier:
// first test
public class Test {
public static void main(String[] args) {
while (true) {
System.out.println("Hi");
}
}
}
Compiler:
javac -g:none Test.java
rename Test.class Test1.class
Créer un fichier:
// second test
public class Test {
public static void main(String[] args) {
for (;;) {
System.out.println("Hi");
}
}
}
Compiler:
javac -g:none Test.java
mv Test.class Test2.class
Comparer:
diff -s Test1.class Test2.class
Files Test1.class and Test2.class are identical
Sur Oracle Java 7, vous obtenez le même code d'octet. Vous ne pouvez pas dire à partir du code d'octet qui utilisait dans l'original. Qui est le meilleur est une question de goût. J'utilise while(true)
Selon le compilateur, il devrait correspondre au même code d'octet.
JVM trouvera le meilleur moyen de faire bytecode et dans les deux cas devrait faire le same.So je pense qu'il n'y a pas de différence. alors que (vrai) est juste plus joli.
J'ai regardé le code d'octet généré et j'ai trouvé que puisque la condition est toujours true (au moment de la compilation), le compilateur compilera le test et se ramifiera toujours en haut de la boucle. Je suppose que continuer déclaration fera également une branche toujours vers le haut de la boucle. Donc, non seulement cela ne fait aucune différence, il n'y a même pas de code généré pour tester quoi que ce soit.
Il compile jusqu'au même code d'octet, et c'est une question de goût quelle construction vous préférez.
J'ai lu beaucoup de code source du JDK distribué Oracle, et je ne me souviens pas facilement que j'ai vu une instruction while(true) dans leur code, mais j'ai vu beaucoup d'instructions for(;;) dans leur code. Moi personnellement, je favorise for(;;) et mon raisonnement va un peu comme ceci:
La boucle while "devrait" nécessiter une expression booléenne, pas une constante booléenne. while(true) est un peu comme if(true), les deux, je pense, n'ont été légalisés que pour le confort supplémentaire des masses. Un while() vide ne compile pas. Ajouter le true là-dedans ressemble un peu au piratage.
for(;;) d'autre part est une "boucle réelle", bien que vide. En outre, il vous permet d'économiser quelques frappes! = ) ( peu importe)
Par conséquent, et je sais que cela semble fou, mais bien que(vrai) lit mieux en anglais, je pense que pour (;;) mieux exprimer votre intention et est plus proche de La Java langage de programmation. Les boucles éternelles devraient être évitées de toute façon. Quand je lis pour (;;), je me sens en sécurité en sachant que le développeur freinera le chemin d'exécution quelque part. Quand je lis while (true), Je ne peux plus en être sûr. Mais bon, peut-être que c'est juste moi! Nous sommes tous libres de choisir notre propre saveur.
Fonctionnellement il n'y a pas de différence. Toute efficacité gagnée ou perdue par une différence de bytecode sera probablement insignifiante par rapport à toute instruction que vous exécuteriez dans le corps de la boucle.
Seule la différence est requise pour l'analyseur, les deux expressions distinctes incluent un nombre différent de jetons à analyser, mais la différence de temps de calcul est très faible et le bytecode compilé est le même pour deux cas.