Schleifenvariable ausserhalb der Schleife benutzen

[hoika]

Hallo #,

das macht man nicht, ich weiss ... ;)
Ich habe hier aber ein altes Projekt,
dort wird das leider benutzt.
Interessanterweise gibt es keine Probleme im Debug-Modus.

Die Variable auch wird nicht direkt danach abgefragt,
sondern ein paar Zeilen später.

Eh ich mich da jetzt durchwurschtel (Code ist nicht von mir),
warum knallt mir das Teil nicht um die Ohren ?

Danke


Heiko

[Bummi]

geraten, schalt mal im Debugmodus die Optimierung and und die Stackframes aus ...

[pjanfred]

Hi,

ich würde es so machen:

nur skizziert:

Code:

for idx = 0 to bla.Count -1 do
begin
  if (idx = bla.Count -1) then
    helpIdx := idx; 
end;

//die Helfer Variabel kann hier genutzt werden
helpIdx := helpIdx -1

desweiteren sollte man noch bei sämtlichen breaks die Helfer Variabel setzen :)

Viel Spaß wünscht
pjanfred

[hoika]

Hallo,

Zitat:

geraten, schalt mal im Debugmodus die Optimierung and und die Stackframes aus ...

Optimierung ist an, Stackframes aus.
Das mit der Hilfsvariable würde ich ja machen,
die Frage ist, warum klappt der Code ?

Heiko

[Luckie]

Zufall. Der Speicher wird eben zufällig nicht weiter genutzt, so dass der Wert nicht überschrieben wird. Aber man sollte sich nicht drauf verlassen.

[himitsu]

Tja, die Gründe wurden ja schon genannt. :-D


aber die korrekten Lösungen:

• Wie es schon gesagt wurde, den Wert irgendwo speichern, bevor die Schleife verlassen wird.
  
• stattdessen z.B. eine While-Schleife verwenden.

PS: helpIdx sollte vorher natürlich noch initialisiert werden.

[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:

Zitat von Delphi-Laie (Beitrag 1136875)

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:

Zitat von Luckie (Beitrag 1136876)

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:

Zitat von himitsu (Beitrag 1136908)

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.

[Luckie]

Zitat:

Zitat von Delphi-Laie (Beitrag 1136909)

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

Gibt es solche Compiler schon? Das Problem ist, woher weiß der Compiler, dass keine Abhängigkeiten bestehen? Woher weiß der Compiler dass keine Synchronisation statt findet, denn nur dann geht das. Der Compiler müsste ja die Programm Logik erfassen und erkennen, was der Programmierer will. Und dann wäre es ja nur noch ein kleiner Schritt bis zu: "Computer mach mal." Und hinten kommt das fertige Programm raus.

[Delphi-Laie]

Ob es so etwas wirklich gibt, ist mir nicht bekannt. Allerdings las ich davon in einem - dezent formuliert - nicht mehr ganz taufrischen Sonderheft der Reihe "Spektrum der Wissenschaft", und zwar eines der Reihe "Verständliche Forschung" von 1989(!). Die Konzepte sind also schon jahrzehntealt. Und Hand auf's Herz: Schon beim flüchtigen Überblicken eine Quellcodes kann man oft sicher parallelisierbare und sicher abhängige (und dann sequentiell auszuführende) Befehle und Blöcker erkennen bzw. unterscheiden.

[Medium]

Auto-Threading ist heikel wie sonst was! Hab mich damit mal ne Zeit theoretisch beschäftigt, und die Generalaussage in der meisten Literatur war (grob): Um eine im allgemeinen Fall überhaupt merkbare Beschleunigung zu erreichen, ist die Komplexität und Fehleranfälligkeit des Vorhabens - aus praktischen Gesichtspunkten - zu groß. Die meisten Autoren waren sich einig, dass es in Summe wohl weniger Arbeit machen würde, an den paar Stellen, an denen es hochspezialisiert effektiv einsetzbar wäre, wenn die Programmierer die jeweils angepasste Lösung manuell implementierten.
Das wird vor allem dann nachvollziehbar, wenn man bedenkt, dass gerade für Multithreading so günstiges Streaming (Operationen wie Daten) derart stark mit den verwendeten Strukturen und der Aufgabe verwoben sind, dass ein Compiler im Grunde "verstehen" müsste, was der Programmierer da gerade machen will, um auch semantische Optimierungen vornehmen zu können - sonst wäre der Gewinn im Mittel kaum merkbar, und wirtschaftlich Unsinn. (Theoretisch nach wie vor höchst interessant!)
Da finde ich es auch irgendwie okay, dass ein Entwickler, der Parallelität herstellen will, sich dieser Sache sehr bewusst sein muss. Dadurch ist er quasi gezwungen geeignete Datenstrukturen und Abläufe zu implementieren, und ggf. sogar einen Algorithmus komplett zu reformulieren um die nötigen Eigenschaften herzustellen.

Ergo: Ein einfacher, "dummer" parallelisierender Compiler wäre sicher machbar, der praktische Nutzen im Mittel aber nicht gegeben. Zumal man sich einen Haufen möglicher Fehlerquellen einbrockt, und sei es schon nur das "wackelige" Debuggen in Threads (vor allem anonymen). Ein intelligenter dieser Art wäre so hochkomplex und würde teilweise in die KI gehen, dass der nötige Entwicklungsaufwand den Nutzen im Mittel kaum gerecht würde, bzw. teilweise nichtmals Theorien zu manchen Details der Umsetzung bestehen. Hochparallele DV ist, gerade durch die Öffnung der GPUs für unspeziellen Code vor kurzem, auch erst recht kurz ein in der Breite diskutiertes Thema. Zuvor war das eher den Spezis von Cray und Co überhaupt ein Anliegen, und so viel Theorie gibt's da einfach noch garnicht zu. Schon garnicht in Punkto Auto-Parallelisierung.

Was du so laks in ein paar Worten als "nice-to-have" nennst, ist ein Universum an Theorie und Komplexität ;)

[hoika]

Hallo,

um noch mal zum Thema zu kommen ;)

Mir ist schon bewusst, dass man das nicht macht (Schleifen-Variable ausserhalb benutzen).
Zum Verständnis:
der Compiler verwendet AX/EAX mit jnz,
was sehr effizient ist, daher auch das Rückwärtszählen,
falls die Variable in der Schleife nicht verwendet wird.
AX/EAX ist aber ein sehr oft verwendetes Register,
es wird also mit grosser Wahrscheinlichkeit
sofort für was anderes benutzt und damit ist der Schleifenzähl-Wert futsch.


Heiko

[Bummi]

zu meiner Zeit war das noch CX

[himitsu]

Der Compiler nimmt, hierfür das, wo er meint das sei noch frei und eigne sich gut dafür.

ECX ist zwar oftmals das Counter-Register, aber es ist nicht zwingend vorgeschrieben.
(das Assemblerbefehl LOOP nutzt zwar dieses Register, aber Delphi nutzt das langsame LOOP eh nicht)

Jenachdem was frei ist, nutzt Delphi EAX, ECX, EDX oder doch ein Plätzchen auf'm Stack.
EBX nutzt Delphi eher ungern, da dieses eine besondere Rolle spielt. (hat aber nix mit dem B zu tun :lol:)

Und da wo der Variablenwert noch lange der Schleife verfügbar war, wurde entweder dieses Register nicht neu beschrieben oder eben die Stelle auf'm Stack war (zufällig) noch unberührt.

[Delphi-Laie]

Zur Ehrenrettung des Compilers sei gesagt: Eine diesbezügliche (berechtigte!) Warnung gibt der Compiler schon bei Delphi 2.0 aus (die Version 1 kann ich dahingehend nicht prüfen, habe sie nicht installiert), vielleicht war das sogar zu Turbo-Pascal-Zeiten schon implementiert....schnell mal eben Turbo-Pascal 6.0 (nie wieder einen solch schnelle und stabile IDE wahrgenommen) gestartet: Dort gibt es keine solche Warnung, und die Variable hat auch den Wert, der ihr zum Ende der Schleife (also zum Start des letzten Schleifendurchlaufes) mit auf den Weg gegeben wurde.

[himitsu]

Der Grund ist ganz einfach:

OK, wenn man die schleife abbricht, dann hat die Variable diesen letzten Wert, aber wie ist das, wenn die Schleife sich ordentlich beendet?

Hat die dann den letzen Wert
- erst prüfen, dann weiterzählen und danach zurückspringen
- erst prüfen, dann zurückspringen und danach weiterzählen :gruebel:
oder ist sie da schon weiter?
- weiterzähen, prüfen ob noch im Bereich dann verlassen oder zurückspringen

PS: Intern läuft die Variable auch manchmal rückwärts, oder eben aus Optimierungsgründen irgendwie anders.
Sie wird dann innerhalb der Schleife umgerechnet, bei deren Nutzung (falls sie überhaupt genutzt wird).

Aber auchßerhalb der Schleife gibt es diese Umrechnung nicht mehr.



Da nun also die Variable nicht unbedingt den Wert hat, welchen man sich vorstellt, kann man dieses danach einfach nicht nutzen,
bzw. manchmal gibt es diese Variable nicht wirklich lange (im RAM), da die nur kurz in einem CPU-Register drin lag.

Und jetzt auf den blosen Verdacht hin, daß diese irgendwer nachher noch verwenden könnte, schaltet der Compiler hier eben nicht alle Optimierungen ab.
Oder komt gar auf die Idee alle Zählervariablen, nach der Schleife, nochmal auf deren "wirklichen" Wert umzurechnen, was reichlich sinnlos wäre und überall einen nutzlosen Overhad bedeuten würde.



Lösung: Geh zu Emba ins EDN, erstelle einen Antrag (QC), man möge doch bitte statt dieser Fehlermeldung eine Umrechnung der Variable einbauen, bzw. dafür sorgen, daß deren Wert in eine richtige Variable kopiert wird.

[Bummi]

@himitsu

ich hatte gestern ein paar Szenarien durchgespielt, egal was man wann wo dazwischengemogelt hat, auch Schleifen dir nachprüfbar wegen Nonseneinhalten wegoptimiert werden, mit/ohne Optimierung etc. stand nach einem for 1 to 10 die Variable immer auf 11.
Wenn man die Anhänge von mir und DeddyH richtig interpretiert, hat der Compiler genügend Intelligenz an solchen Stellen die Optimierung nicht durchzuführen.

Aber eigentlich ist die ganze Diskussion müssig, weil wir alle seit Jahren anders arbeiten ....

[himitsu]

Jupp, könnte sein, daß der Compiler inzwischen intelligent genug ist.
Diese Meldung ist ja schon historisch alt.

Darum ja der Vorschlag mit dem QC.

[p80286]

Meiner Erfahrung nach ist i am Ende der for-Schleife dann nicht definiert, wenn i nicht für weitere Operationen (

Delphi-Quellcode:

inc(j,i);

) heran gezogen wird.
Falls i nach der Schleife noch genutzt wird, nutze ich Repeat .. until oder while, was in den meisten Fällen auch besser lesbar ist.
(Arrays in Records etc. )



Gruß
K-H

[Furtbichler]

Sagt mal, der Compiler wird ja wohl nicht so dämlich sein, und den Variableninhalt überschreiben, bevor auf ihn zugegriffen wird.

Delphi-Quellcode:

For i:=1 to 10 do SomethingWith(i);
//
// Einige Zeit später
//
Writeln(i);

Muss immer funktionieren. Es ist eben nur so, das entweder die 0 oder 11 drin steht (denke ich). Deshalb 'unbestimmt'.

[Bummi]

es steht immer die 11 drin...

[stahli]

Ich hatte das mal getestet:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var
  I: Integer;
begin
  for I := 0 to Memo1.Lines.Count - 1 do
    Memo2.Lines.Add(Memo1.Lines[I]);
  Memo2.Lines.Add('->' + IntToStr(I));
end;

Wenn Count = 0 ist (also bis -1 bzw. gar nicht gezählt wird) enthält I einen Zufallswert (124567 o.ä.).

Es wäre ja nicht schlecht, wenn der Compiler wenigstens -1 in I schreiben würde, aber da lässt sich natürlich drüber streiten.
Jedenfalls wäre es nicht schädlich und würde weniger Probleme verursachen.

[Delphi-Laie]

Zitat:

Zitat von Furtbichler (Beitrag 1137061)

Sagt mal, der Compiler wird ja wohl nicht so dämlich sein, und den Variableninhalt überschreiben, bevor auf ihn zugegriffen wird.

Delphi-Quellcode:

For i:=1 to 10 do SomethingWith(i);
//
// Einige Zeit später
//
Writeln(i);

Muss immer funktionieren. Es ist eben nur so, das entweder die 0 oder 11 drin steht (denke ich). Deshalb 'unbestimmt'.

Der Compiler ist nicht dämlich, weil er nichts verändert, sondern erst das Programm (Compilat), wenn es läuft.

Wie Bummi es schon erwähnt: Der Wert um eins höher. Wird also nach der letzten Schleife noch einmal um 1 erhöht, um dann festzustellen, daß die (For-)Schleifenbedingung nicht mehr erfüllt ist -> Schleifenabbruch.

Der - in dieser Hinsicht intelligente - Compiler gibt zudem einen Warnhinweis aus: "For-Schleifenvariable kann nach Durchlauf undefiniert sein".

[Furtbichler]

Ja ja, in dem einen Fall ist die Schleifenvariable um eins höher, is schon klar. Aber was ist, wenn der Compiler so optimiert, das rückwärts gezählt wird? Steht dann auch 11 drin?

Ich glaube nicht (hab kein Delphi), und daher ist der Inhalt eben 'unbestimmt', weil manchmal so, manchmal so.

Dessenungeachtet ist es irrelevant, denn wir fassen die Laufvariable eh nicht an, gelle?

[Luckie]

Ich wollte gerade sagen, akzeptieren wir es doch einfach, dass sie unbestimmt sein kann und nutzen sie einfach nach der Schleife nicht mehr.

[Delphi-Laie]

Zitat:

Zitat von Furtbichler (Beitrag 1137092)

Dessenungeachtet ist es irrelevant, denn wir fassen die Laufvariable eh nicht an, gelle?

Innerhalb der Schleife natürlich nicht, obwohl es durchaus sinnvolle Ausnahmen von dieser Regel geben könnte.

Außerhalb der Schleife ist es mit dem Artenschutz der Variable bei mir vorbei (s.o.), doch dort ist sie ohnehin keine Laufvariable.

[Sir Rufo]

Zitat:

Zitat von Delphi-Laie (Beitrag 1137096)

Zitat:

Zitat von Furtbichler (Beitrag 1137092)

Dessenungeachtet ist es irrelevant, denn wir fassen die Laufvariable eh nicht an, gelle?

Innerhalb der Schleife natürlich nicht, obwohl es durchaus sinnvolle Ausnahmen von dieser Regel geben könnte.

Außerhalb der Schleife ist es mit dem Artenschutz der Variable bei mir vorbei (s.o.), doch dort ist sie ohnehin keine Laufvariable.

Die Variable darf man ausserhalb der Schleife benutzen wie man möchte ... nur der Wert derselbigen ist nach der Schliefe immer als nicht initialisiert anzusehen ;)

[Furtbichler]

Zitat:

Zitat von Sir Rufo (Beitrag 1137110)

Die Variable darf man ausserhalb der Schleife benutzen wie man möchte ...

Sagen wir mal so: In einem Programmiererteam ist das so eine Sache mit dem 'benutzen wie man möchte'. Das geht, sofern man akzeptiert, das die Kollegen einen teeren und federn, wie sie möchten.

[Sir Rufo]

Zitat:

Zitat von Furtbichler (Beitrag 1137111)

Zitat:

Zitat von Sir Rufo (Beitrag 1137110)

Die Variable darf man ausserhalb der Schleife benutzen wie man möchte ...

Sagen wir mal so: In einem Programmiererteam ist das so eine Sache mit dem 'benutzen wie man möchte'. Das geht, sofern man akzeptiert, das die Kollegen einen teeren und federn, wie sie möchten.

Warum sollten die?

[stahli]

Wenn man eine Weile (mit Delphi) programmiert, sollte das "Problem" händelbar sein.
Es stellt sich wohl eher die Frage, womit Ein- und Umsteiger rechnen.
Vermutlich laufen die meisten Anfänger mal in die Falle.
Daher wäre es nett, wenn das Problem (durch eine kleine Compileranpassung) abgestellt werden würde.

Aber letztlich ist es vermutlich nicht wert, das Forum damit voll zu schreiben ;-)