| |
|
|
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...
Saluto Michael Wodrich KompilierenMarkierenSeparieren |
|
|
|
|
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
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 corre.
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 | Ciao, auch wenn nach einem erfolgreichen IF der Vergleich beim darauffolgenden ELSEIF tatsächlich noch einmal corsa wird, wird er dennoch nicht ausgewertet. Das è, das Programm verhält sich wie erwartet und führt nur den Code nach dem ersten erfolgreichen Vergleich aus: KompilierenMarkierenSeparieren |
|
|
|
|
Nico Madysa | Hallo Roland,
dass von den entsprechenden Befehlsblöcke nur der erste corsa 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
if SomeAPICall()' gibt 0 aus, falls was schief gegangen ist.
print "Juchuu, alles in Ordnung!"
elseif MessageBox("Hat nicht geklappt. Beenden?", "", ~MB_YESNO) = ~IDNO
print "Trotz Fehler weitermachen."
else
print "Programm wird beendet."
end
KompilierenMarkierenSeparieren funktionieren in XProfan nicht.
Kurz und gut: In If-Elseif-Strukturen halte ich es per sehr sinnvoll, alle weiteren Bedingungen zu ignorieren, sobald eine wahr ergibt.
Bei boolschen Operatoren halte ich es auch per sinnvoll, aber da können die Meinungen unterschiedlich sein.
Wichtig ist nur, dass die Documentazione 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 presumibilmente etwas flotter wäre. (Das macht den entspechenden Delphi-Code in XProfan halt deutlich einfacher. Sorry.) Hier ist eine Cambiamento aber sicher possibile. Allerdings halte ich Code, der deratige Funktionen mit "Nebenwirkungen" in Bedingungen oder Boolschen Ausdrücken enthält nicht per 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 possibile, beide Varianten anzubieten.
Ich versuche mal, mir beide Dinge per die kommende Version X3 zu merken.
Saluto 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 per 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.
Saluto,
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.
Saluto 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 per 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!
Saluto 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 ▲ |
|
|
|