' schrieb:Deinem "mal wieder" nach scheine ich ja für Dich im oberlehrerhaften Nachbesseren von suboptimalen VIs schon eine bekannte Größe zu sein.
Das du gewartet hast, war nicht ernst gemeint.
Ach komm, fühl Dich bitte nicht angegriffen. Das "mal wieder" bezieht sich ja ausschlißlich auf meine Lösungsvorschläge. Ich weiß ja schließlich, dass ich die Weißheit nicht mit Löffeln gefresen habe.
Das hat auch nichts mit oberlehrerhaften Nachbesseren zu tun. Das ist einfach nur deine Erfahrung, welche Du freundlicherweise mit Anderen teilst. Dafür hast Du (jeder) meine volle Unterstützung.
Guckst du hier
oder hier
Edit:
Aber du musst zugeben, diesmal war ich nah dran.

' schrieb:eine For-Schleife mit Abbruchbedingung ist für mich eine While-Schleife.
Rein Programmtechnisch gesehen schon aber ganz anders sieht die Sache aus, wenn man die Ausführungsgesgeschwindigkeiten vergleicht.
Daß eine For Schleife - zumindest bei hohen Iterationszahlen - wesentlich schneller ist als eine While -Schleife, hat sich ja schon herumgesprochen. Das Gleiche gilt aber auch für ein For-Schleife mit Abbruchbedinung im Vergleich zur While-Schleife.
Der Grund ist: in einer Wileschleife mit Ausgangs-Indexing ist dem System überhaupt nicht bekannt, wie groß das Array maximal werden kann. Entsprechend wird während der Operation Seicherplatz immer wieder neu bereitgestellt, und das kostet Zeit. Bei einer For- Schleife mit Abbruchbedingung hingegen, z.B mit N=1 000 000, die nach ca. 500 000 Durchgängen abgebrochen wird, ist die maximale Speichergröße von vornherein bekannt und wird entsprechend von Anfang an zur Verfügung gestellt.
Fazit: wenn man bei einer While-Schleife die maximal zu erwartende Indexzahl kennt, dann lohnt es sich immer, sie durch eine For-Schleife mit Bedingungsanschluß zu ersetzen.