array[1..10] auf Wert prüfen?

[Dennis07]

Aber wenn es dich so krass stört, die Ergebnisvariable als Schleifenvariable zu verwenden, dann bitte...

Delphi-Quellcode:

function AssertArray(AArray: TArray<Boolean>): Boolean;
var
  Current: Boolean;
begin
  for Current in AArray do
  begin
    if not Current then
    begin
      Exit(False);
    end;
  end;
  Result := True;
end;

[hoika]

Hallo,

Zitat:

Innerhalb der Schleife würde das beim Zugriff auf diese Variable wieder umgegreht, falls diese Variable überhaupt ausgelesen wird, aber nach der Schleife bleibt i eventuell bei 0 oder sogar -1 stehen, was man versteht, da das INC/DEC vor der Abbruchbedingung liegen könnte und der Vergleich mit 0 kürzeren optimaleren Prozessor-Code erzeugt.

Das ist nicht ganz korrekt.
Wenn die Schleifenvariable innerhalb der Schleife nicht benutzt wird, optimiert das der Compiler,
weil ein Compare mit 0 als Endergebnis der Schleifenvariable schneller ist.

Wird die Schleifenvariable innerhalb der Schleife benutzt, zählt der "Compiler richtig".

Und eine Schleifenvariable darf eh nicht außerhalb der Schleife benutzt werden.
Das bringt auch hoffentlich eine Compilerwarnung, wenn es trotzdem versucht wird.

[p80286]

Zitat von hoika:

Und eine Schleifenvariable darf eh nicht außerhalb der Schleife benutzt werden.
Das bringt auch hoffentlich eine Compilerwarnung, wenn es trotzdem versucht wird.

Unglücklich formuliert:

Delphi-Quellcode:

var i : integer;
  text:string;
begin
  text:='';
  for i:=1 to 7 do
    text:=text+'m';
  for i:=1 to 5 do
    text:=text+'n';
  //showmessage(text+inttostr(i));

das funktoniert ohne Warnung

während das

Delphi-Quellcode:

var i : integer;
  text:string;
begin
  text:='';
  for i:=1 to 7 do
    text:=text+'m';
  for i:=1 to 5 do
    text:=text+'n';
  showmessage(text+inttostr(i));

eine Warnung nach sich zieht.

[Warnung] Unit1.pas(35): FOR-Schleifenvariable 'i' kann nach Durchlauf undefiniert sein

Also eher "der Zugriff auf die Schleifenvariable ohne erneut einen Wert zugewiesen zu haben"

Gruß
K-H

[hoika]

Hallo,
warum sollte Dein erstes Code-Stück eine Warnung erzeugen?

Zitat:

Also eher "der Zugriff auf die Schleifenvariable ohne erneut einen Wert zugewiesen zu haben"

Jein, die Schleifenvariable steht meistens in einem Register (ax,eax usw.).
Dieser Registerinhalt kann nach "einer Weile" Code hinter der Schleife einfach einen anderen Wert haben.

[Dennis07]

Zitat von hoika:

Und eine Schleifenvariable darf eh nicht außerhalb der Schleife benutzt werden.
Das bringt auch hoffentlich eine Compilerwarnung, wenn es trotzdem versucht wird.

Das ist nicht ganz richtig. Es wird keine Wahrnung deshalb ausgegeben, weil es eine Schleifenvariable ist, sondern nur deshalb, weil sie bei einer for -Schleife möglicherweise undefiniert sein könnte (nämlich ist sie das genau immer dann, wenn die Schleife kein einziges mal durchlaufen wurde). Die selbe Wahrnung wird dir aber auch ausgegeben, wenn du auf eine andere Variable zum Lesen zugreifst, die vorher möglicherweise nicht initialisiert wurde. Deshalb kommt es immer auf den Einzelfall an, und nur weil eine Wahrnung ausgegeben wurde, heißt es noch lange nicht, dass das gesagte auch stimmen muss. Der Compiler durchblickt deinen Quellcode eben nur bis zu einem gewissen Punkt.

Zitat von hoika:

Jein, die Schleifenvariable steht meistens in einem Register (ax,eax usw.).

Für gewöhnlich eher in ECX (Das "C" steht nämlich für "counter").
Wobei das durchaus schonmal variieren kann, je nach dem, wie die Routine sonst noch so aussieht. Das EAX-Register würde aber ohnehin nicht viel Sinn ergeben, da dort ja das Ergebnis der Funktion in der Regel drin steht.

[Dennis07]

Zitat von hoika:

Dieser Registerinhalt kann nach "einer Weile" Code hinter der Schleife einfach einen anderen Wert haben.

Und nein, das stimmt einfach nicht. Sorry, aber das ist falsch.
Die Zählervariable ist eine ganz normale Variable, die vor oder auch danach einen festen Wert hat/haben kann.
Deshalb kannst du ja auch 2 for -Schleifen hintereinander packen ohne dass es zu Problemen kommt.

Delphi-Quellcode:

program CountTo100;

var
  I: Integer;
begin
  for I := 1 to 50 do WriteLn(I);
  WriteLn('Halbzeit');
  for I := Succ(I) to 100 do WriteLn(I);
  WriteLn('Fertig');
end.

Das funktioniert so einwandfrei, und da wird nichts "umgepackt". Der Compiler managet deine Variablen schon alle, und das ohne dir da irgendwas zu überschreiben. Und schon überhaupt nicht überschreibt der dir die Ergebnisvariable irgendwo im Code, ohne, dass du das willst. Wenn es mehr Variablen/Parameter als Register gibt, dann werden Sachen auf dem Stack abgelegt.

[himitsu]

Code:

...
50
Halbzeit
52
...

sieht nicht ganz richtig aus.

[bernau]

Zitat von Dennis07:

Delphi-Quellcode:

program CountTo100;

var
  I: Integer;
begin
  for I := 1 to 50 do WriteLn(I);
  WriteLn('Halbzeit');
  for I := Succ(I) to 100 do WriteLn(I);
  WriteLn('Fertig');
end.

Ab WriteLn('Halbzeit') hat I keinen definierten Zustand. D.h. Succ(I) produziert in der zweiten Schleife einen zufälligen Wert. Kann sein, dass es jetzt für dich (zufällig) funktioniert. Würde ich mich aber nicht drauf verlassen.

[himitsu]

Was ich ja bereits gesagt hatte:
Außerhalb der Schleife ist die Schleifenvariable undefiniert, also es wird nicht "garantiert", dass sie dort einen bestimmten wert hat.

Dass sie es doch mal haben kann, ist eine andere Sache, auf die man sich aber niemals verlassen kann.
Die Variable kann/darf man außerhalb auch gern wiederverwenden, für eine andere Schleife oder für sonstwas, aber dort hat man sie natürlich vorer zu initialisieren.

Eigentlich wäre es konsequent, wenn der Compiler hier seinen "Variable wurde initialisiert"-Status nach der Schleife zurücksetzt.
Aber es ist hier das gleiche Problem wie mit nichtinitialisierten Funktions-Results, welche ebenfalls nicht "bemängelt" werden, wenn es sich um einen gemanagten Typen ala String handelt, da er ja per se initilisiert ist (außerhalb der Funktion), aber ihr dennoch keinen "definierten" Initialwert besitzt.


Für Schleifen in C++ ist das was anderes, denn dort "definierst" DU was wie mit der Variable passiert.

Code:

for (i = 0; i < 10; i++)

[Dennis07]

Zitat von himitsu:

Code:

...
50
Halbzeit
52
...

sieht nicht ganz richtig aus.

Jo, hast recht. Hatte es nur unter FPC eben im Browser getestet, und da zählt der bei 51 weiter. Unter Delphi bei 52. Ist ja auch egal, FPC interessiert mich sowieso nicht wirklich. In Delphi und SMS bekomm muss ich nur das Succ weg lassen, und bekomme 51.

Zitat von bernau:

Ab WriteLn('Halbzeit') hat I keinen definierten Zustand. D.h. Succ(I) produziert in der zweiten Schleife einen zufälligen Wert. Kann sein, dass es jetzt für dich (zufällig) funktioniert. Würde ich mich aber nicht drauf verlassen.

Das stimmt doch nicht. Der Wert, den Succ(I) zurückgibt, ist immer der selbe. Ich habe es jetzt spaßeshalber mal mit 5 verschiedenen Konstellationen einige Male durchgespielt, und die Schleifenvariable war in keinem einzigen Fall undefiniert, so lange die Schleife mindestens 1 mal durchlaufen wurde. Warum sollte sie das auch sein, es wurde ja im späteren Verlauf nichts reingeschrieben.

Bitte, und das geht jetzt auch an alle anderen, die meinen, dass das nur "eine glückliche Ausnahme" sei: Schickt mir mal einen einzigen Code-Schnipsel, in dem das nicht der Fall ist, und ich nehme alles wieder zurück und gebe zu, dass ich falsch lag. Aber bisher habe ich noch nichts dergleichen bemerkt. for -Schleifen, die durchlaufen, behalten ihren Wert hinterher.

Ich habe anbei mal den ASM-Code für eine Leere For-Schleife von 1 bis 5 mit angehängt. Da sieht man ziemlich gut, wie eine For-Schleife funktioniert, und auch, dass immer nach oben gezählt wird.