Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Die Schleife bricht also nur dann ab, wenn CONDITION false ist und sollte man gar nichts für CONDITION angeben, dann gibt es auch keine Abbruchbedingung, weshalb die Schleife ewig läuft. Macht doch Sinn, oder?
Nicht bei Java, da die JVM den Code analysiert und wenn im Schleifenbody nichts geschieht, wird der gesamte Ausdruck (früher oder später) wegoptimiert. Das macht Performance-Messungen mitunter auch so schwierig, weil man etwas völlig anderes messen kann als beabsichtigt bzw. die JVM erst etwas arbeiten lassen muss, um realistische Ergebnisse zu erhalten.
@soares: Ich habe meine Assage nicht auf die Performancediskussion bezogen, sondern cumulonimbus8 die Logik einer for-Schleife erklären wollen. Was die JVM für optimierungen am Code durchführt ist für die Logik einer for-Schleife komplett irrelevant. Wie Madman1209 schon erwähnt hat, haben einige hier den Sarkasmus in Kanibals Post nicht gefunden, weshalb die Diskussion eine unglückliche Wendung genommen hat, mein Post sollte jedoch nicht in Bezug auf diese Diskussion gesehen werden.
Wenn wir jedoch schon dabei sind, dann würde mich noch interessieren, wie du das "wird der gesamte Ausdruck (früher oder später) wegoptimiert" meinst? Ich kann mir nämlich nicht vorstellen, dass die JVM eine Endlosschleife wegoptimiert, das würde dann nämlich nicht dem ursprünglichen Code entsprechen und wäre mehr eine Abänderung als eine Optimierung.
Der DirectX Compiler (und OpenGL wahrscheinlich auch) optimiert tatsächlich "echte" Endlosschleifen weg, allerdings nur, solange sie wirklich trivial sind. Sobald darin irgendetwas passiert, hängt sich meist der Compiler dann auf/braucht ewig oder erkennt das.
@Hancock: Wirklich? Hätte mir nicht gedacht, dass irgend ein Compiler sowas macht. Das ist nämlich ein recht gravierender Eingriff in das Verhalten des Programms. Wird bei DirectX bzw. OpenGL zwar eher keine Probleme machen, denn ich kann mir keine Situation ausdenken, bei der man auf eine leere Endlosschleife angewiesen ist, finde es aber trotzdem recht brutal.
Ich war auch überrascht, aber nachdem es auf der Grafikkarte "normales" Threading nicht gibt, seh ich z.B. keinen Grund, jemals eine Endlosschleife zu verwenden. aber wenigstens warnt der Compiler "warning X3557: loop doesn't seem to do anything, forcing loop to unroll".
Und auf Grafikkarten sind Endlosschleifen unangenehm, weil da die Grafikkarte abstürzt ("Der Anzeigetreiber wurde wiederhergestellt, weil er nicht reagiert hat").
Solange der Compiler eine Warnung ausgibt finde ich es nicht so schlimm, dann weiß man ja, dass der Code nicht das macht was man erwarten würde. Endlosschleifen machen auf Grafikkarten aber wirklich keinen Sinn, deshalb sollte diese Eigenheit des DirectX ( und OpenGL ) Compilers kaum ein Problem darstellen.
Nicht bei Java, da die JVM den Code analysiert und wenn im Schleifenbody nichts geschieht, wird der gesamte Ausdruck (früher oder später) wegoptimiert. Das macht Performance-Messungen mitunter auch so schwierig, weil man etwas völlig anderes messen kann als beabsichtigt bzw. die JVM erst etwas arbeiten lassen muss, um realistische Ergebnisse zu erhalten.
das ist so falsch! ja, code welcher nichts tut wird wegoptimiert. das trifft auf diese whileschleife aber nicht zu! lediglich ihr body (sofern sie denn einen hätte) könnte wegoptimiert werden.
die endlosschlefie bleibt aber, denn das wäre eine änderung des ablaufs und des ergebnisses was keine optimierung wäre.
aber was redet ihr hier eigenltich noch?
wie ich schon auf seite eins schrieb ist der grund für diese endlosschleife doch völlig offensichtlich, wenn man sich mal den code im link anschaut.