Wieso funktioniert diese boolsche Schleife nicht?

[Popov]

Mal ein Beispiel. In der Prozedur Button1Click rufe ich in einer Schleife eine Funktion mehrmals auf. Die kann False oder True zurückgeben. Bei der Gelegenheit will ich ermitteln ob der Rückgabewert mindestens einmal True war. Nach meiner Logik kann ich das mit b := b or Test(i); machen. Wenn mindestens einmal True zurückkommt, ist b auch True.

Das Problem ist, dass wenn b True ist, wird die Funktion nicht weiter aufgerufen. Warum?

Delphi-Quellcode:

function Test(i: Integer): Boolean;
begin
  ShowMessage('Zahl ist: ' + IntToStr(i));
  Result := (i mod 2) = 0; //Einfach etwas sinnloses, hauptsache gelegentlich True
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  i: Integer;
  b: Boolean;
begin
  b := False;
  for i := 0 to 8 do
    b := b or Test(i);

  ShowMessage(BoolToStr(b));
end;

[BUG]

Das hängt mit dem "Kurzschlussverfahren" zusammen.

Es gibt drei Lösungen:

1. Benutze eine Zwischenvariable für das Funktionsergebnis.
2. Schalte das "Kurzschlussverfahren" mit einem Compilerschalter aus.
3. Vertausche die beiden Argumente des OR-Operators.

Ich würde Variante 1 empfehlen, da das die Intention klarer macht (Funktion wird auf jeden Fall aufgerufen). Insgesamt ist es eine gute Idee, wenn Sachen wie "Test" (Getter/math. Funktionen) seiteneffektfrei sind (kein Showmessage); dann wäre dir diese Optimierung nämlich gar nicht auf die Füße gefallen.

[Popov]

Ach ja, klar. True kann nicht "trueer" werden, also ist der Aufruf der Funktion unnötig. Hab nicht dran gedacht. Hab mich nur gewundert, da ich es schon mal machte, nur damals eben richtig.

Und was das ShowMessage angeht, das ist nur für das Beispiel (spart den Debugger).

[himitsu]

Vielleicht hattest du es andersrum gemacht?
b := Test(i) or b;

Oder du hattest an den Compileroptionen rumgespielt.



Und keine Sorge, die Variable mit b or Test könnte eh nicht wegoptiomiert werden.
Bei Test or b wäre es aber möglich, aber ich glaub auch da bleibt es noch da.



Aber wegen des Bolls, kann man ja notfalls immernoch den ersten Post bearbeiten.
Auch wenn es irdendwie wie eine If-Schleife klingt.

[himitsu]

Man kann meine Antwort natürlich auch als Beispiel ansehen und nur das Prinzip betrachten.

[Aphton]

Die Compileroption würde ich nicht wirklich ändern, ist ja auch gefährlich - z.B. wegen soewtas:

Delphi-Quellcode:

  if (isConnected() or tryToConnect()) then
    // blabla

Wenn isConnected() true zurückliefert, dann wird ein Verbindungsaufbau per tryToConnect() nicht gemacht, da der zweite Operand beim OR nicht evaluiert wird.
Schaltet mans nun aus, dann wird er aber, was manchmal, je nachdem wie ordentlich programmiert wurde, zu blöden Fehlern führen kann.

Das ist übrigens auch nur ein einfaches Beispiel, da gibts sicher komplexere Konstrukte..

[hoika]

Hallo,
gerade das letzte Beispiel würde ich sofort auseinandernehmen.
Wer soll so etwas debuggen?

Heiko

[Brunhilde]

Hallo,
ihr diskutiert gerade über die boolesche Algebra.

0 or 0 = 0
1 or 0 = 1
0 or 1 = 1
1 or 1 = 1

Wenn die erste Abfrage in einer or Verbindung True ergibt wird die zweite nicht mehr ausgeführt weil sie keine Auswirkung auf das Ergebnis hat. Der Compiler optimiert sie raus.

Bei einem and statt or würden beide ausgeführt.
0 and 0 = 0
1 and 0 = 0
0 and 1 = 0
1 and 1 = 1

Der Compiler würde die zweite Funktion nicht weg optimieren weil sich das Ergebnis ändern könnte sie muss sogar ausgeführt werden.

Frohes Osterfest

[Helmi]

bei "OR" kann die zweite Abfrage wegoptimiert werden, wenn die erste Abfrage bereits true ergibt

Truer als true gibt's nicht

Ist die erste Abfrage false, dann wird noch die 2. Abfrage benötigt
Ist die erste Abfrage schon true, dann wird die 2. Abfrage nicht mehr benötigt

---------------------------------------------------------------------------------------------------------------

bei "AND" kann auch die zweite Abfrage wegoptimiert werden, wenn die erste Abfrage bereits false ergibt

Falser als false gibt's nicht

Ist die erste Abfrage true, dann wird noch die 2. Abfrage benötigt
Ist die erste Abfrage false, dann wird die 2. Abfrage nicht mehr benötigt


"kann" aus dem Grund, da man diese Funktion/Option ausschalten kann

[Perlsau]

Zitat von hoika:

Hallo, gerade das letzte Beispiel würde ich sofort auseinandernehmen. Wer soll so etwas debuggen?

Meintest du das hier:

Delphi-Quellcode:

  if (isConnected() 
  or tryToConnect()) then
    // blabla

Wenn man das untereinander statt in einer Zeile schreibt, springt der Debugger doch die zweite Zeile an, wenn die erste False ergibt, oder?