Schleifenvariable ausserhalb der Schleife benutzen

[Delphi-Laie]

So ganz verstanden habe ich nicht, worin der Frevel liegen soll.

Also, man nimmt eine Variable als Zählvariable für eine Zählschleife. Während und nach dem letzten (Zähl-)Schleifendurchlauf(es) sollte diese Variable den Wert haben, der mit to bzw. downto festgelegt wurde.

Wird während des Schleifendurchlaufes (so etwas würde sogar ich nicht tun) oder nach dem Schleifendurchlauf nicht wieder schreibend auf diese Variable zugegriffen, müßte doch der letzte to- bzw. downto-Wert in dieser auch nach dem Verlassen der Schleife konserviert bleiben und unverfälscht wieder gelesen werden können. Oder doch nicht?

[Luckie]

Nein, nach dem Verlassen der for-Schleife ist der Wert der Zählvariablen unbestimmt, weil sie nach der Schleife weggeschmissen wird. Das sagt dir aber auch der Compiler, wenn du die Warnungen nicht deaktiviert hast.

[DeddyH]

Zitat von Delphi-Laie:

Oder doch nicht?

Oder doch nicht: http://docwiki.embarcadero.com/RADSt...n_%28Delphi%29

[Bummi]

wieder mal zu spät, ich hatte folgendes gefunden:
http://docwiki.embarcadero.com/RADSt...e_sein_(Delphi)

[Delphi-Laie]

Dank Euch, also wieder etwas hinzugelernt.

Nun, den letzten Wert der Zählschleife entnähme ich ohnehin nicht der Laufvariable nach der Schleife. Die Laufvariable vor oder nach der Zählschleife für irgendetwas anderes einzusetzen (rezyklieren, bei mir wird nichts weggeworfen, "nichts darf umkommen"), bin ich allerdings kein Kind von Traurigkeit, sondern gehe speicherbewußt sparsam mit Variablen um.

Ergänzung:

Zitat von Luckie:

Nein, nach dem Verlassen der for-Schleife ist der Wert der Zählvariablen unbestimmt, weil sie nach der Schleife weggeschmissen wird. Das sagt dir aber auch der Compiler, wenn du die Warnungen nicht deaktiviert hast.

Luckie, Du meinstest wohl oder sicherlich, er wird weggeworfen, also der Wert der Variablen, nicht sie, die Variable selbst.

[Luckie]

Na ja, OK. Wenn man es genau ausdrückt, der Wert.

Aber ich würde davon abraten, Variablen zu "recyceln". Weil dann entweder keine eindeutige Benennung möglich ist oder die Benennung nicht mehr passt. Beides ist schlechter Code, weil es die Les- und Wartbarkeit verringert. Und sei wir doch mal ehrlich, die paar Byte auf dem Stack zusätzlich machen den Braten auch nicht fett. Da würde ich mir eher andere Stellen im Code zum optimieren vornehmen.

[himitsu]

Wobei der Compiler ja auch intelligent genug sein könnte, um zu erkennen, daß die Variablen nicht gleichzeitig verwendet werden
und würde dann den selben Speicher für Beide gemeinsam nutzen.

[Delphi-Laie]

Zitat von himitsu:

Wobei der Compiler ja auch intelligent genug sein könnte, um zu erkennen, daß die Variablen nicht gleichzeitig verwendet werden
und würde dann den selben Speicher für Beide gemeinsam nutzen.

Gleichzeitig nicht, aber eine Variable kann sequentiell bzw. zeitversetzt für alles mögliche genutzt werden. Bei Werteüberschneidungen wegen gleichzeitiger Benutzung, die wahrscheinlich zu inkosistentem Verhalten des Compilates führen, erwarte ich von einem Delphi der Generation XE2, daß es das grundsätzlich bemerkt und warnt, sofern das nach der (Un-)Logik des Quelltextes nicht ausgeschlossen werden kann.

Compiler kann man durchaus noch viel intelligenter bauen. So kann z.B. ein Compiler Codeabschnitte bzw. einzelne Befehle, die nicht kausal im Zusammenhang stehen, automatisch parallelisieren, sozusagen bei so etwas wie ein selbständiges "Threadmanagemen" erstellen bzw. durchführen (natürlich mit Compilerschaltern zu-/abschaltbar, abhängig von der Prozessoren- oder Prozessorenkernanzahl, auch die ungefähre Codegröße, die das auslöst usw.). Was man alles in einen solchen Compiler hineinzaubern könnte...! Und daß Delphi dergleichen bis heute nicht bietet....Mit solchen Mosereien hielt ich mich bisher aber bewußt zurück, und daß Delphi das nicht bietet, ist für mich als Hobbyprogrammierer kein echter Nachteil. Und die Sprache Pascal ist ja zum Glück gut les- und strukturierbar, deshalb mag ich (auch) Delphi.