| |
|
|
Nico Madysa |
|
|
| |
|
|
|
Michael Wodrich | Öhhhmm
Wenn man sowohl im IF-Teil als auch in allen anderen Zweigen den gleichen Wert benutzt, dann würde auch ich ins Schleudern kommen...
und bei Funktionsaufrufen fehlt XProfan ganz offensichtlich die Glaskugel - also aufrufen und schauen was dabei heraus kommt...
Welche Programmiersprache geht denn hier anders vor - und wie genau...
Gruß Michael Wodrich KompilierenMarkierenSeparieren Wenn der Callback nicht in der gleichen IF-Struktur steht, sondern in einer eigenen, dann wird dies sicher auch funktionieren. |
|
|
| |
|
|
|
Michael Wodrich | |
|
| |
|
|
|
Nico Madysa | Hallo Michael,
so ziemlich jede Sprache, die mir spontan einfällt, führt die Ausdrücke in einem elseif-Zweig nur aus, wenn alle Ausdrücke davor falsch ergeben haben.
Bei den C-artigen Sprachen ist das automatisch der Fall, weil deren elseif ja gerade nichts Anderes als verschachtelte Ifs sind.
Habe auch eben Python getestet:
a = 0
if a == 0:
print "Division durch Null verboten!"
elif 3 / a > 8:
print "Dieser Zweig wird nie erreicht, da a Null ist."
stürzt nicht ab. Da die erste Bedingung schon erfüllt ist, wird die zweite gar nicht erst getestet. Das analoge Gegenstück unter XProfan stürzt mit einem Division-durch-Null-Fehler ab. |
|
|
| |
|
|
|
Michael Wodrich | Hier arbeitet XProfan also genau anders herum als C:
- bei den If-ElseIf fällt XProfan durch zum nächsten Block - und bei den Select-Case ist dies bei C der Fall (deshalb muss dort im Block immer mit BREAK gestoppt werden)
Solange die Bedingungen vollkommen unterschiedlich sind, fällt es ja auch niemandem auf, das hier etwas aus dem Ruder läuft.
In gewollter Form sollte dies aber nur bei den einzeiligen CASE(NOT) so sein - hier können dann mehrere ähnliche oder gleiche Fälle abgehandelt werden.
Roland hat's sich ja schon durchgelesen... |
|
|
| |
|
|
|
RGH | Hallo, auch wenn nach einem erfolgreichen IF der Vergleich beim darauffolgenden ELSEIF tatsächlich noch einmal ausgeführt wird, wird er dennoch nicht ausgewertet. Das heißt, das Programm verhält sich wie erwartet und führt nur den Code nach dem ersten erfolgreichen Vergleich aus: KompilierenMarkierenSeparieren Andererseits besteht hier noch eine Möglichkeit den Ablauf zu optimieren, da nach dem ersten erfolgreichen IF bzw. ELSEIF die weiteren gar nicht mehr beachtet werden müssten ..
Gruß Roland |
|
|
| XProfan X2Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 25.02.2014 ▲ |
|
|
|
|
Nico Madysa | Hallo Roland,
dass von den entsprechenden Befehlsblöcke nur der erste ausgeführt wird, dessen Bedingung zutrifft, ist selbstverständlich. Alles Andere wäre ja wirklich ein Skandal.
Worum es mir viel mehr geht, ist, wann genau die Bedingungen ausgewertet werden. Das ist in zwei Situationen wichtig:
1. Wenn eine Funktion in der Bedingung steht, die irgendwelche Nebenwirkungen hat. KompilierenMarkierenSeparieren Derzeit zeigt XProfan die MessageBox in jedem Falle an, während Sprachen wie C, Python, etc. (was Delphi macht, weiß ich nicht) die MessageBox nur zeigen, wenn SomeAPICall einen Fehler verursacht hat.
2. Wichtig ist es auch dann, wenn eine Funktion in der Bedingung einen Fehler verursachen könnte. Beispiele dafür haben wir bereits einige hier.
If hatte ein ähnliches Thema schon einmal angeschnitten. Damals gings darum, dass XProfan bei boolschen Operatoren alle Argumente auswerten, auch wenn sie nicht benötigt werden. Ausdrücke wie KompilierenMarkierenSeparieren funktionieren in XProfan nicht.
Kurz und gut: In If-Elseif-Strukturen halte ich es für sehr sinnvoll, alle weiteren Bedingungen zu ignorieren, sobald eine wahr ergibt.
Bei boolschen Operatoren halte ich es auch für sinnvoll, aber da können die Meinungen unterschiedlich sein.
Wichtig ist nur, dass die Dokumentation irgendwo erwähnt, wie XProfan sich verhält. Damit man nicht im Dunkeln tapst. |
|
|
| |
|
|
|
RGH | Ja, derzeit wertet XProfan tatsächlich auch die anderen Bedingungen aus. Das ist aber schon immer so gewesen, auch wenn es in der Tat nicht notwendig ist und anders sogar vermutlich etwas flotter wäre. (Das macht den entspechenden Delphi-Code in XProfan halt deutlich einfacher. Sorry.) Hier ist eine Änderung aber sicher möglich. Allerdings halte ich Code, der deratige Funktionen mit "Nebenwirkungen" in Bedingungen oder Boolschen Ausdrücken enthält nicht für sonderlich übersichtlich.
Zu den Boolschen Operatoren: In Delphi kann man tatsächlich per Compilerschalter einstellen, ob immer alle Argumente ausgewertet werden oder nur so weit, bis das Ergebnis feststeht. ich habe es immer auf "alle Argumente" eingestellt und in XProfan ist es auch so realisiert. Aber auch hier wäre es sicher möglich, beide Varianten anzubieten.
Ich versuche mal, mir beide Dinge für die kommende Version X3 zu merken.
Gruß Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 25.02.2014 ▲ |
|
|
|
|
Nico Madysa | Alles klar, danke für die schnelle Antwort. Wie bereits gesagt, letztendlich sind beide Vorgehensweisen (vollständige und Kurzschlussauswertung) gangbare Alternativen. Aber wichtig ist halt, dass der Programmierer auch irgendwo darüber aufgeklärt wird.
Gruß,
Nico |
|
|
| |
|
|
|
RGH | ... und die Sache mit dem ELSEIF wird in der nächsten XProfan-Version (X3) und in FreeProfan korrigiert! Sobald ein Zweig erfüllt wurde, werden die übrigen Bedingungen nicht mehr abgefragt.
Gruß Roland |
|
|
| XProfan X2Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 26.02.2014 ▲ |
|
|
|
|
Nico Madysa | Vergiss nicht, das gleiche Verhalten auch für Select einzubauen. Hat zwar absolut Null Anwendungsorientierung, aber das Letzte, was wir brauchen, sind noch mehr Inkonsistenzen. |
|
|
| |
|
|
|
RGH | ... und auch bei SELECT nun entsprechend angepasst!
Gruß Roland |
|
|
| XProfan X2Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 25.09.2014 ▲ |
|
|
|