Is AND-operator short-circuiting in Pascal?

[MitjaStachowiak]

Hallo,
sory für den englischen Titel, aber ich glaube auf Deutsch ist die Begrifflichkeit nicht geläufig

Ich habe gerade den Artikel zu extended pascal überflogen und dort wird ein extra and_then-Operator definiert, der die Eigenschaft bieten soll, dass die rechte Seite nicht ausgewertet wird, wenn die linke Seite false ist. Ich habe aber mal rasch getestet, was der normale and-Operator tut und da wird auch nicht ausgewertet, wenn nicht erforderlich. Auch nicht, wenn man die Optimierungen deaktiviert.

Ist also ein code, wie

Code: Alles auswählen

if (myObj <> nil) and (myObj.isReady) then doSomething;

offiziell safe? Im Wiki zum and-Operator steht das nicht...

[theo]

https://www.freepascal.org/docs-html/cu ... ogsu4.html

[MitjaStachowiak]

Hmm, das sollte mal noch im Wiki erwähnt werden. (Ich schau mal die Tage). Wobei ich allgemein finde, dass etwaige Unterscheidungen für short-circuiting fester Bestandteil der Programmiersprache sein sollten und kein Compiler-Flag. Naja.

Ungeklärt auch, ob bei komplexeren booleschen Ausdrücken, eine Optimierung hier aktiv wird. Also man kann ja ggf. Logikoptimierung machen und darüber die Reihenfolge der Therme verändern...

[af0815]

Hmm, das sollte mal noch im Wiki erwähnt werden. (Ich schau mal die Tage). Wobei ich allgemein finde, dass etwaige Unterscheidungen für short-circuiting fester Bestandteil der Programmiersprache sein sollten und kein Compiler-Flag. Naja.

Naja, man muss dabei beachten das die verschiedenen Varianten von Pascal die der FPC beherrscht das nicht bedingt. Das Wiki ist für solchen Sachen nicht so relevant, sondern der Programmier Guide. Das die einzig wirklich gültige Referenz über den Compiler. Das Flag kenne ich IMHO aus Delphi, ich bin mir jetzt nicht ganz sicher, aber das könnte bereits in Turbo Pascal drinnen gewesen sein.

Ergänzung: Ja ist es siehe TP 5.0 Guide Seite 57 ( http://bitsavers.org/pdf/borland/turbo_ ... e_1989.pdf )
Zitat:

The evaluation model is controlled through the $B compiler directive. The
default state is {$B-} (unless changed using the Options/Compiler menu),
and in this state short-circuit evaluation code is generated. In the {$B+}
state, complete evaluation code is generated.

[m.fuchs]

Wobei ich allgemein finde, dass etwaige Unterscheidungen für short-circuiting fester Bestandteil der Programmiersprache sein sollten und kein Compiler-Flag.

Da bin ich ganz bei - diese Informationen hier haben mich auch sehr überrascht und ich halte diese Variante auch für gefährlich.
Leider sehe ich nicht, das ein Vorschlag zu Änderung irgendeine Chance in der Umsetzung hätte. Dafür ist das Verhalten schon zu lange implementiert.

[af0815]

Wieso jetzt auf einmal gefährlich, sind die Programmierer in den letzten 30 Jahren verblödet ?

Es ist seit den Zeiten von TP ein Standard eingehalten worden. Wenn man es unbedingt anders braucht, so kann man das Umstellen. Die Defaultparameter machen seit ewigen Zeiten absoluten Sinn. Es gab da vor 3 Jahrzehnten eine Diskussion für und gegen die Short-Circuiting. Damals mit den Aufkommen von Objekten wurde plötzlich das kurze Verfahren bevorzugt, da man das Objekt auf gültig prüfen kann bevor man einen Zugriff macht. Das war damals das Killerfeature für {$B-} als Standard. Müsste im Archiv kramen, ob man das nicht händisch bei den ersten Versionen von TP eintragen musste (TP 3.0 für CP/M).

BTW: Ja ich habe mit TP 3.0 auf CP/M und MS-DOS angefangen, so 1986/87 auf Philips P2000C.

[Winni]

Hi!

Zumindestens bei Version 4.0 war als Standard-Einstellung boolean short-circuit an:

Version 4.0 assumes short-circuit Boolean evaluation. This means that
evaluation of Boolean expressions is halted as soon as possible.

Aus :

http://bitsavers.informatik.uni-stuttga ... _1987.pdf

Bei Version 3.0 bin ich mir nicht sicher, weil 4.0 endlich das Unit-Konzept einführte, das sie von UCSD-Pascal "gestolen" hatten. Mit den riesigen include-Files von 3.0 hab ich mich nie anfreunden können und lieber mit UCSD gearbeitet.

Winni

[m.fuchs]

Wieso jetzt auf einmal gefährlich, sind die Programmierer in den letzten 30 Jahren verblödet ?

Nun, anscheinend bin ich blöde. Zumindest so blöd, dass ich erwarte dass nicht einfach Aufrufe wegoptimiert werden.
Klar, ich hätte mir auch die Beschreibung in den Docs mal durchlesen können - solch eine Optimierung habe ich einfach nicht erwartet.

Wie dem auch sei: aus meiner Sicht wäre eine Unterscheidung der Optimierung durch unterschiedliche Operatoren wie and und andalso oder so etwas die bessere Wahl.
Die kann man in seinem Code je nach Notwendigkeit einsetzen.

[Winni]

Hi!

Bitte nicht schon wieder diese Diskussion aus den End-80ern!

Die lässt sich kurz so zusammenfassen:

Wer halbwegs sauberen Code schreibt, ist mit boolean short-circuit auf der völlig sicheren Seite.

Nicht so viel um die heilige Kuh Objekt-Orientierung rumtanzen, sondern erstmal um die Grundlagen kümmern.

Winni

[af0815]

Wenn der erste Term nicht zutrifft, warum sind dann die anderen Terme wichtig ? Und die Reihenfolge ist seit Jahrzehnten festgelegt. Da braucht man keine (sorry) Idiotensicherung mit unterschiedlichen Operatoren.

Ok, ich habe vielleicht im Laufe der Zeit (zu) viel Erfahrung angehäuft. Aber woher kommt Erfahrung, wenn du kapierst warum es dich auf die Schnauze gehauen hat. Krönchen richten und weiter (und daraus lernen, bis Alzheimer zuschlägt).

Bitte nicht schon wieder diese Diskussion aus den End-80ern!

He he wer mit dem richtigen Alter und noch keinem Alzheimer (SCNR)

[wp_xyz]

Trotzdem sollte man die Augen offen halten. Bloß weil Boolean-Short-Circuit-Evaluation in "if"-Ausdrücken immer richtig ist, heißt nicht, dass das unter allen Umständen so ist. Ein verwandtes Thema ist z.B. die Funktion IfThen, die ein paar Codezeilen einsparen kann. Aber: Hier werden alle Ausdrücke ausgewertet und berechnet. Code wie folgt führt zum Absturz, wenn x = 0 ist:

Code: Alles auswählen

program Project1;
uses Math;
var x, y, Flaeche: Integer;
begin
  Flaeche := 10;
  for x := 0 to 5 do
    WriteLn('x=', x, 'y=', IfThen(x<>0, Flaeche/x, Infinity));
end. 

[af0815]

Code: Alles auswählen

    WriteLn('x=', x, 'y=', IfThen(x<>0, Flaeche/x, Infinity));

In dem Beispiel wird IMHO auch absolut keine Boolean-Short-Circuit-Evaluation verwendet. IFTHEN hat einfach 3 Parameter. Warum sollte dort das greifen ?

[m.fuchs]

Bitte nicht schon wieder diese Diskussion aus den End-80ern!

Wie immer ein völlig verfehlter Rant von Winni.

Wer halbwegs sauberen Code schreibt, ist mit boolean short-circuit auf der völlig sicheren Seite.

Nicht zwangsläufig. Tatsächlich bin ich bisher noch nicht darüber gestolpert. Für die Zukunft weiß ich jetzt aber: wenn ich zwei Funktionen ausführen und deren Rückgabewerte per and verknüpfen möchte, dann muss ich Hilfsvariablen benutzen. Kommt sicher selten vor, aber kann auch vorkommen.

Nicht so viel um die heilige Kuh Objekt-Orientierung rumtanzen, sondern erstmal um die Grundlagen kümmern.

Noch so ein sinnfreier Kommentar. Das eine hat mit dem anderen nix zu tun. Und die Grundlage ist ja erst einmal Aussagenlogik. Dass die - in der sonst recht sauberen Sprache Pascal - nicht ganz umgesetzt sondern eine Optimierung verwendet wird ist ja das Problem. Ach halt, es liegt gar nicht an Pascal. N. Wirth hatte Short-Circuit nicht vorgesehen. Unter anderem damit der Compiler eventuell auch die Reihenfolge der Aussagen verändern kann. Hmmmm.

[wp_xyz]

Code: Alles auswählen

    WriteLn('x=', x, 'y=', IfThen(x<>0, Flaeche/x, Infinity));

In dem Beispiel wird IMHO auch absolut keine Boolean-Short-Circuit-Evaluation verwendet. IFTHEN hat einfach 3 Parameter. Warum sollte dort das greifen ?

Hab ich auch nicht behauptet. Es geht mir genau um deine Aussage. Wenn man die Bool-Short-Circuit-Evaluation im Kopf hat, tief verankert, könnte man ja auch die Idee haben, es würde auch beim IfThen gelten. Ich zumindest bin schon öfter in diese Falle getappt.

[af0815]

Unter anderem damit der Compiler eventuell auch die Reihenfolge der Aussagen verändern kann. Hmmmm.

Ich glaube das kann nur PascalDragon beantworten
Das sind fragen die nur ein Compilercrack kennen kann, alles andere ist Spekulation auf +10 Grad warmen Eis