Hallo, in einem eineren Forum habe ich das 1. Beispiel gefunden und ich dachte ich verstehe das Ergebnis. Neugierig habe ich dann ein ähnliches Beispiel konstruiert, aber ich wundere mich über das Ergebnis des 2. Beispieles. Programmiersprache ist C. Ich habe beide Beispiele mit Visual Studio und mit Dev C++ getestet. Beides mal das gleiche Ergebnis. x = 5; y = x++ == 4 || x == 5; Ergebnis: x=6 und y=0 OK x = 5; y = x == 5 || (x++ == 5); Ergebnis: x=5 und y=1 Warum wird in dem zweiten Beispiel das x++ nicht ausgeführt? Gruß Helmut
Gast
#4976492
Weil der erste Teil der if-Bedingung
1 | |
wahr ist => Der zweite Teil wird gar nicht mehr ausgeführt (Warum sollte er auch - das Ergebnis des ORs steht ja schon fest).
Weil die Auswertung des logischen Oder (||) nach dem ersten Ausdruck (x==5) abgebrochen wird, da das Ergebnis danach bereits feststeht.
Gast
#4976495
Weil der erste Teilausdruck bereits als wahr ausgewertet wird. Gruß J
Hallo, vielen Dank fuer die schnellen Antworten. Ich hatte immer nur an die Rangordnung(precedence) der Operatoren gedacht. Gruss, Helmut
Gast
#4976504
"Kurzschlussauswertung" Dachte immer, in der deutschen Sprache würde es auch "Short-circuit Evaluation" genannt.
Helmut S. schrieb: > Hallo, > > vielen Dank fuer die schnellen Antworten. Ich hatte immer nur an die > Rangordnung(precedence) der Operatoren gedacht. > > Gruss, > Helmut Wenn man keinen "Kurzschluß" will, kann man auch mit | bitweise verodern. Funktioniert mit beliebigen integer-Werten, wozu auch bool gehört, das alles was irgendwie ein gesetztes Bit hat, "wahr" ist. Bei & statt && ist das differenzierter zu betrachten, denn
1 | |
weil sich eben ungleich gesetzte Bits maskieren.
Carl D. schrieb: > Helmut S. schrieb: >> Hallo, >> >> vielen Dank fuer die schnellen Antworten. Ich hatte immer nur an die >> Rangordnung(precedence) der Operatoren gedacht. >> >> Gruss, >> Helmut > > Wenn man keinen "Kurzschluß" will, kann man auch mit | bitweise > verodern. Funktioniert mit beliebigen integer-Werten, wozu auch bool > gehört, das alles was irgendwie ein gesetztes Bit hat, "wahr" ist. Sofern das Ergebnis nur als boolescher Wert genutzt wird und nicht zwingend nur 0 oder 1 sein darf. Aber gerade dann würde ich auf jeden Fall || hinschreiben, denn das dokumentiert die Absicht besser. Abgesehen davon ist das Beispiel des TE nur mit || definiert. Mit | ergibt sich undefiniertes Verhalten. Sinnvoller wäre in dem Fall, das x++ da rauszuziehen. Dann ist auch der "Kurzschluss" egal. Der stört ja nur, wenn auf der rechten Seite etwas steht, das Nebeneffekte hat und auf jeden Fall ausgeführt werden muss.
Mein Beispiel war nur für mich zum Üben bezüglich der Rangordnung von Operatoren. Ich würde niemals so eine Zeile tatsächlich verwenden.
Gast
#4976950
>Ich würde niemals...
Das hatten wir früher auch mal gedacht. Heute finden wir das normal, gut
lesbar. Den Stiel, den sie uns in der Ausbildung beibrachten, empfinden
wir Heute als unentzifferbar verwirrend.
Rolf M. schrieb: > Abgesehen davon ist das Beispiel des TE nur mit || definiert. Mit | > ergibt sich undefiniertes Verhalten. Das ist richtig. Hier ist auch eine Beschreibung, warum das so ist. https://en.wikipedia.org/wiki/Sequence_point Im Prinzip ist bei || festgelegt, dass alles links davon ausgewertet werden muss, bevor der rechte Teil ausgewertet wird. Bei | ist das nicht der Fall und der Compiler dürft z.B. das x++ auch erst nach dem x == 5 auswertet.
Gast
#4984720
Helmut S. schrieb: > Ich würde niemals so eine Zeile tatsächlich verwenden. Das gibt aber in anderen Sprachen so nett lesbare Zeilen wie
1 | |
MfG Klaus
Klaus schrieb: > Helmut S. schrieb: >> Ich würde niemals so eine Zeile tatsächlich verwenden. > > Das gibt aber in anderen Sprachen so nett lesbare Zeilen wie >
1 | |
2 | |
Ausgerechnet Perl als "nett lesbar" zu bezeichnen, erscheint mir dann doch ein wenig... gewagt. ;-)
Naja, Perl schenkt einem neben "||" und "&&" eben auch die niedriger priorisierten auch "or" und "and". Damit ist die Zeile tatsächlich gut lesbar und offensichtlich. Man muss eben nur eine Menge wissen, und da Perl hauptsächlich aus syntaktischem Zucker besteht...
Gast
#4984772
Sheeva P. schrieb: > Ausgerechnet Perl als "nett lesbar" zu bezeichnen, erscheint mir dann > doch ein wenig... gewagt. ;-) Na gut, "stirb!" ist nicht wirklich nett. Aber: argv[3] or "DefaultFile.name" klingt doch besser, or? MfG Klaus
S. R. schrieb: > Naja, Perl schenkt einem neben "||" und "&&" eben auch die niedriger > priorisierten auch "or" und "and". Damit ist die Zeile tatsächlich gut > lesbar und offensichtlich. > > Man muss eben nur eine Menge wissen, und da Perl hauptsächlich aus > syntaktischem Zucker besteht... Perl war mehr als fünfzehn Jahre meine Feld-, Wald- und Wiesenskriptsprache und daher nahezu täglich im Gebrauch. Insofern kenne ich Perl ganz gut und weiß, daß man damit durchaus halbwegs lesbaren Code schreiben kann -- wenn man Erfahrung, Disziplin und ein bisschen Mühe investiert. Aber verglichen mit modernen Skriptsprachen wie Python oder Lua... ;-)
Klaus schrieb: > Na gut, "stirb!" ist nicht wirklich nett. Gerade das war einer der Teile von Perl, die ich wirklich gemocht habe. Viel schöner als
1 | |
2 | |
3 | |
4 | |
5 | |
Noch viel schicker finde ich da allerdings so etwas wie in Python:
1 | |
Da muß ich nämlich gar kein eigenes Errorhandling betreiben: wenn Python
die Datei nicht öffnen kann, wirft es eine aussagekräftige Exception
(IOError: No such file or directory: 'filename').
> Aber: argv[3] or "DefaultFile.name" klingt doch besser, or?
"DefaultFile.name" klingt für mich auch nicht toll: CamelCase, aber
nicht konsequent durchgezogen. Ist das irgendwas microsoftes?