Warum wird x++ wird nicht ausgeführt

[Helmut S. (helmuts)]

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

[Toni Tester (Gast)]

Weil der erste Teil der if-Bedingung

x == 5

wahr ist => Der zweite Teil wird gar nicht mehr ausgeführt (Warum sollte 
er auch - das Ergebnis des ORs steht ja schon fest).

[Tassilo H. (tassilo_h)]

Weil die Auswertung des logischen Oder (||) nach dem ersten Ausdruck 
(x==5) abgebrochen wird, da das Ergebnis danach bereits feststeht.

[jj (Gast)]

Weil der erste Teilausdruck bereits als wahr ausgewertet wird.

Gruß J

[Helmut S. (helmuts)]

Hallo,

vielen Dank fuer die schnellen Antworten. Ich hatte immer nur an die 
Rangordnung(precedence) der Operatoren gedacht.

Gruss,
Helmut

[Noch einer (Gast)]

"Kurzschlussauswertung"

Dachte immer, in der deutschen Sprache würde es auch "Short-circuit 
Evaluation" genannt.

[Carl D. (jcw2)]

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

(0x10 & 0x01) != (0x10 && 0x01)

weil sich eben ungleich gesetzte Bits maskieren.

[Rolf M. (rmagnus)]

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.

[Helmut S. (helmuts)]

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.

[Noch einer (Gast)]

>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.

[M.K. B. (mkbit)]

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.

[Klaus (Gast)]

Helmut S. schrieb:
> Ich würde niemals so eine Zeile tatsächlich verwenden.

Das gibt aber in anderen Sprachen so nett lesbare Zeilen wie

open( FILE, "<filename" ) or die "Cannot open filename: $!\n";

MfG Klaus

[Sheeva P. (sheevaplug)]

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
>

> open( FILE, "<filename" ) or die "Cannot open filename: $!\n";
>

Ausgerechnet Perl als "nett lesbar" zu bezeichnen, erscheint mir dann 
doch ein wenig... gewagt. ;-)

[S. R. (svenska)]

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...

[Klaus (Gast)]

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

[Sheeva P. (sheevaplug)]

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... ;-)

[Sheeva P. (sheevaplug)]

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

FILE* fp = fopen("filename", "r");
if( ! fp ) {
    fprintf(stderr, "Could not open file: %s\n", "filename");
    exit(1);
}

Noch viel schicker finde ich da allerdings so etwas wie in Python:

ifh = open("filename", "r")

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?