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

Delphi-Quellcode:

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?

Delphi-Quellcode:

b := Test(i) or b;

Oder du hattest an den Compileroptionen rumgespielt. :stupid:



Und keine Sorge, die Variable mit

Delphi-Quellcode:

b or Test

könnte eh nicht wegoptiomiert werden.
Bei

Delphi-Quellcode:

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. :angle2:
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. :roll:

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

Zitat von hoika (Beitrag 1296218)

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?

[himitsu]

Jupp, Delphi ist "standardmäßig" so eingestellt, daß es die Algebra verkürzt und mit der Auswertung aufhört, wenn das Endergebnis bereits feststeht.

Code:

0 or 0   = 0
1 or (0) = 1   <<<<<<
0 or 1   = 1
1 or (1) = 1   <<<<<<

0 and (0) = 0
1 and 0   = 0
0 and (1) = 0
1 and 1   = 1

Das in Klammern wird garnicht mehr ausgewertet und genau deswegen wurde die Funktion auh nicht mehr aufgerufen.

Und da gemeint war, daß es schonmal ging, blieben erstmal nur zwei Gründe übrig, siehe meine erste Antwort. (abgesehn von anderen Gründen/Sonderfällen, die im Beispiel des TE weggelassen wurden)

• verkürzte Auswertung deaktiviert
• andersrum ausgewertet (Funktion zuerst)

Weiß auch nicht was er meinte (vielleicht in den gelöschten Texten? (hab deren Inhalt nicht mehr ganz im Kopf)
Man kann es zwar so schreiben

Delphi-Quellcode:

if isConnected() then
  if tryToConnect() then

Aber ich geh einfach nach dem Motto, wer "global" ein grundsätzliches Standardverhalten ändert, der hat halt Pech. :twisted:
Wobei ich micht nun doch manchmal darauf einlass und bei meinen Units/Komponenten (die ich für andere freigeb), gewisse Einstellungen lokal sicherheitshalber nochmal in der Unit vorgebe.

[Popov]

Bei der Ganzen Diskussion wird der eigentliche Sinn von

Delphi-Quellcode:

b := b or Test(i);

ignoriert, und zwar die effiziente Art festzustellen ob es im Code mindestens einmal True gab, bzw. im eigentlichen Code eine Fehlermeldung. Mehr nicht. Der Code hat also das gemacht was er machen sollte, abgebrochen als es irgendwann eine Fehlermeldung gab. Ich hab nur vor lauter Bäume den Wald nicht gesehen und mich auf den Abbruch konzentriert, obwohl das eigentlich das war was ich damit erreichen wollte. Bei

Delphi-Quellcode:

b := b or Test(i);

wird Test (i) nicht mehr ausgeführt, weil es keinen Sinn hat, bei

Delphi-Quellcode:

b := Test(i) or b;

wird er ausgeführt, nur um gleich mit einer Fehlermeldung abzubrechen.

[BadenPower]

Wenn Du nur wissen möchtest, ob die Testauswertung 1x True ergeben hat, dann kannst Du auch die Schleife sofort verlassen.

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
   begin
    if (Test(i)) then
     begin
      b := true;
      break;
     end;
   end;

  ShowMessage(BoolToStr(b));
end;

Ist meiner Meinung nach noch effizienter.

[himitsu]

nja, zumindestens in dem anfänglichen Beispielcode ist damit die Schleife kaum effizienter, denn letztendlich kommt der Code ja auf Folgendes hinaus.

Delphi-Quellcode:

for i := 0 to 8 do
  if not b then 
    b := Test(i)
  {else
    b := b};

Also effektiv nur noch ein

Delphi-Quellcode:

if b then continue;

in der Schleife, welches noch maximal 8 Mal ausgeführt wird.

Aber auch wenn dein Code "länger" ist, so zeigt er zumindestens die "Funktion" etwas deutlicher.

Zitat:

hör auf, wenn gefunden (true)

[Popov]

Nein, will ich nicht. Wie ich schon sagte, #1 ist nur ein Beispiel, dass das Wesentliche zusammengefasst. Eben auf das Ermitteln ob schlussendlich mindestens eines der Rückgabewerte True war. Im eigentlichen Programm werden verschiedene Funktionen aufgerufen und am Ende will ich wissen ob mindestens eines davon kein Ergebnis geliefert hat. Die Schleife war nur dazu da, damit die Funktion mehrmals aufgerufen wird. Ich hätte sie auch in drei Zeilen hintereinander aufrufen können.

[Daniel]

Die Ausgangsfrage scheint mir hinreichend geklärt.
Wenn Ihr noch etwas hinzufügen möchtet, dann konzentriert Euch bitte auf das Thema.