Is AND-operator short-circuiting in Pascal?

[PascalDragon]

Ist Short-Circuiting aktiv, so ändert der Compiler die Reihenfolge nicht. Ist es nicht aktiv, macht der Compiler da in der Tat Optimierungen, wenn es sich anbietet.

Das wäre eine Information die in die Referenz https://www.freepascal.org/docs-html/cu ... ogsu4.html IMHO hineingehören würde. Weil damit ist es klar und definiert, wie der Compiler sich verhält.

Dann melde bitte einen Bug gegen die Dokumentation.

Wir werden wahrscheinlich irgendwann mal Unterstützung für and_then und or_then aus ISO Extended Pascal einbauen.

Da aktuell ja das normale and standardgemäß genau das tut, fände ich m.fuchs Vorschlag besser, das so zu lassen und den no-short-circuiting-Fall mit andAlso sowie orAlso anzubieten, statt mit {$push}{$B-}[...]{$pop}.

So Sachen, wie

Code: Alles auswählen

if (obj <> nil) and (obj.ready) then ...
if (length(arr) > 0) and (arr[0] = x) then ...

sind schon so geläufig, dass man das Verhalten des regulären and nicht mehr ändern kann.

Wir werden kein andAlso oder was auch immer einführen. Das einzige was wir einführen werden sind die besagten and_then und or_then, da die für ISO Extended Pascal Kompatibilität benötigt werden. Ansonsten werden wir da an nichts rütteln, auch nicht an dem Standardwert von $B (außer, wie ich gerade sehe, für die ISO Pascal and ISO Extended Pascal Modi, da dort der Standard die volle Auswertung sein sollte), da wir nicht einfach so mit neuen Schlüsselwörtern um uns schmeißen, nur weil irgendjemand es nicht passt, wie sich die Sprache und Implementierung entwickelt hat.

Wie wäre es bei Methoden, Funktionen oder Properties mit einer Art unaltering-Direktive?

Ich bin nach etwas Nachdenken zu dem Schluss gekommen, dass FPC bei mehrfachen Peroperty-Zugriffen in einem Ausdruck nicht erkennen kann, ob man die durch Optimierungen zusammenfassen kann. Es kann ja z.B. sein, das ein Property eine Art Caching durchführt, sodass im Getter schon ein Schreibzugriff passiert. Nur dass es hier trotzdem egal ist, wie oft das property abgefragt wird. Der Compiler könnte den Zugriff also in einem Register puffern...

Sobald im Getter ein Schreibzugriff passiert ist das nicht mehr - um den C++ Ausdruck zu nutzen - „const”. Aber ich spiele selbst durchaus auch mit dem Gedanken den Compiler versuchen zu lassen Funktionen, die wirklich keinen Schreibzugriff nach außen durchführen entsprechend (intern) zu markieren, so dass der Compiler da besser optimieren kann.

A propos Optimierung: wenn ein if-Ausdruck keine Funktionsaufrufe und Seiteneffekte enthält und die Bedingungen nicht zu komplex sind, schaltet der Compiler selbst die volle Auswertung für diesen Ausdruck ein, um ihn besser optimieren zu können (im Idealfall geht das dann nämlich ohne Sprünge )

[af0815]

Wir werden kein andAlso oder was auch immer einführen. Das einzige was wir einführen werden sind die besagten and_then und or_then, da die für ISO Extended Pascal Kompatibilität benötigt werden. Ansonsten werden wir da an nichts rütteln, auch nicht an dem Standardwert von $B (außer, wie ich gerade sehe, für die ISO Pascal and ISO Extended Pascal Modi, da dort der Standard die volle Auswertung sein sollte), da wir nicht einfach so mit neuen Schlüsselwörtern um uns schmeißen, nur weil irgendjemand es nicht passt, wie sich die Sprache und Implementierung entwickelt hat.

+1

[m.fuchs]

Ich sehe keinen Sinn in andAlso bzw. orAlso. Bisher sind die mir wirklich nicht abgegangen.

In dem Vergleich nach and könnte eine Funktion aufgerufen werden, die globale Variablen ändert. Bei B+ wird die sicher aufgerufen bei B- nur dann, wenn der Ausdruck vor dem and true ergibt.

Wenn Erfolgsrückmeldungen mehrerer Funktionsaufrufe zusammengefasst werden sollen und trotzdem sichergestellt werden soll dass jeder Aufruf erfolgt.
Ist zugegebenermaßen eher selten, aber man muss diese Info im Hinterkopf behalten. Mir war es einfach neu, dass an dieser Stelle so fröhlich wegoptimiert wird.

Wir werden kein andAlso oder was auch immer einführen. Das einzige was wir einführen werden sind die besagten and_then und or_then, da die für ISO Extended Pascal Kompatibilität benötigt werden. Ansonsten werden wir da an nichts rütteln, auch nicht an dem Standardwert von $B (außer, wie ich gerade sehe, für die ISO Pascal and ISO Extended Pascal Modi, da dort der Standard die volle Auswertung sein sollte), da wir nicht einfach so mit neuen Schlüsselwörtern um uns schmeißen, nur weil irgendjemand es nicht passt, wie sich die Sprache und Implementierung entwickelt hat.

Jo, ich hatte auch nicht erwartet dass etwas, was so lange existiert, geändert wird. Da sind die Risiken das alter Code nicht mehr funktioniert viel zu hoch.

Wie gesagt, mir war das nur völlig neu und ich hab das Verhalten einfach nicht erwartet. Ich speichere es jetzt im Hinterkopf zusammen mit den anderen fragwürdigen Entscheidungen von Borland ab - wie Interfaces rein für COM zu missbrauchen oder die typisierten "Konstanten".