C: Bedingte Anweisung "if"

[Georg M. (g_m)]

Was ist der Unterschied zwischen

 if(a > b && c > d)
 {
   . . . . . . . .
 }

und

 if(a > b)
 {
   if(c > d)
   {
     . . . . . . . .
   }
 }

?

[Michael B. (laberkopp)]

Georg M. schrieb:
> Was ist der Unterschied

Kompiliert in Maschinenbefehle kommt dasselbe raus

Beim zweiten kannst du mehr else-Zweige nutzen.

[Bruno V. (bruno_v)]

Ist beides wirklich das gleiche. Auch in der Ausführung:
Wenn a>b, dann wird c>d nicht mehr abgefragt/ausgeführt.
a>b wird garantiert vor c>d abgefragt.

Bei einfachen Zahlen/Variablen ist das egal. Wenn c oder d jedoch 
Makro/Funktion/HW-Register sind, dann kann das wichtig sein. Und beide 
Versionen verhalten sich exakt gleich (solange a,b,c oder d kein Makro 
ist, dass irgendeine ganz andere Sache macht)

[Obelix X. (obelix)]

Bruno V. schrieb:
> Wenn a>b, dann wird c>d nicht mehr abgefragt/ausgeführt.

Da fehlt das Wörtchen "nur" und das "nicht" ist zu viel.

Nur wenn a>b, dann wird c>d ausgewertet.

Bei ODER "||" wäre dein Satz richtig. Gilt dann aber nicht mehr für den 
zweiten Snipped.

[Wastl (hartundweichware)]

Obelix X. schrieb:
> Nur wenn a>b, dann wird c>d ausgewertet.

Ist die Abarbeitung ohne Klammerung nicht von rechts nach links?

[Obelix X. (obelix)]

Warum sollte? Würde Michael und Bruno widersprechen. Und der Satz von 
Bruno wäre dann immer noch nicht richtiger.

[Wastl (hartundweichware)]

Wenn die Abarbeitung von rechts nach links geschieht (ich
weiss es nicht ob es so ist) dann würde erst c>d ausgewertet
und ggf. a>b nicht.

Obelix X. schrieb:
> Nur wenn a>b, dann wird c>d ausgewertet.

[Axel S. (a-za-z0-9)]

Georg M. schrieb:
> Was ist der Unterschied zwischen

[schnipp]

Logisch ist es das gleiche. Ob der gleiche Maschinencode dabei 
herauskommt, hängt vom Compiler und der Optimierungstufe ab.

Variante 1 ist aber kompakter und IMHO auch leichter lesbar.

[Matthias T. (matthiasthiele)]

Wie bereits geschrieben: in vielen Fällen wird der Compiler den gleichen 
Code erzeugen. Im Compiler Explorer kannst Du Dir das auch anzeigen 
lassen.

[Bruno V. (bruno_v)]

Obelix X. schrieb:
> Nur wenn a>b, dann wird c>d ausgewertet.

Sorry. Natürlich völlig richtig.

Genauso wie im if-Schachtelcode.

[Arduino F. (Firma: Gast) (arduinof)]

Georg M. schrieb:
> Was ist der Unterschied zwischen

Was ist der Kern/Grund deiner Frage?

Warum ich das Frage:
Ein solche Frage hätte ich evtl. von einem Einsteiger erwartet.
Nicht von jemandem mit bald 4000 Postings auf dem Buckel.
Da steckt also wohl was anderes dahinter....

[Harald K. (kirnbichler)]

Wastl schrieb:
> Ist die Abarbeitung ohne Klammerung nicht von rechts nach links?

Nein.

int *p;

p = NULL;


if (p && *p == 4)
{
}

Würde von rechts nach links ausgewertet, stürzte das mit einer 
Nullpointer-Exception ab.
Tut es aber nicht, da eben von links nach rechts ausgewertet wird.

[Sebastian W. (wangnick)]

Harald K. schrieb:
> Tut es aber nicht, da eben von links nach rechts ausgewertet wird.

Genau. Man sollte Assoziativität und Abarbeitungsreihenfolge nicht in 
einen Topf werfen: "Precedence and associativity are independent from 
order of evaluation."

https://en.cppreference.com/w/c/language/operator_precedence

https://en.cppreference.com/w/c/language/eval_order

LG, Sebastian

[Tilo R. (joey5337)]

Harald K. schrieb:
> Wastl schrieb:
>> Ist die Abarbeitung ohne Klammerung nicht von rechts nach links?
>
> Nein.
>
>

> int *p;
> 
> p = NULL;
> 
> 
> if (p && *p == 4)
> {
> }
>

>
> Würde von rechts nach links ausgewertet, stürzte das mit einer
> Nullpointer-Exception ab.
> Tut es aber nicht, da eben von links nach rechts ausgewertet wird.

Thou shalt not follow the NULL pointer, for chaos and madness await thee 
at its end!

Etwas ausprobieren ist keine valide Taktik in C, weil es sein kann, dass 
du dabei undefined behaviour nutzt.
Der Compiler geht davon aus, dass der Programmierer weiß was er tut. 
Dein Code darf kein undefined behaviour enthalten und der Compiler ist 
frei, unter dieser Annahme beliebige Optimierungen durchzuführen. Es 
kann sein, dass das mit deinem aktuellen Compiler und den aktuellen 
Einstellungen funktioniert und der Code genau das macht, was du 
erwartest. Genau so gut kann das irgendwann in der Zukunft aber auch 
nicht mehr so sein. Dann hast du einen fiesen Fehler in gut 
abgehangenem, getestetem und seit Jahren zuverlässigem Code.

(Das war nur als allgemeine Warnung gedacht, dein Beispiel ist ok. Ich 
gehe sogar davon aus, dass für genau diesen &&-Anwendungsfall die 
Compiler eine optimierte Implementierung haben.)

[Cyblord -. (cyblord)]

Tilo R. schrieb:
> (Das war nur als allgemeine Warnung gedacht, dein Beispiel ist ok.

Und deshalb ist dein ganzes Post Unsinn.

Es ist normal dass man Pointer auf NULL testet bevor man drauf zugreift. 
Und die Reihenfolge ist eben genau festgelegt und kein Zufall und kein 
undefined behaviour.

[Tilo R. (joey5337)]

Cyblord -. schrieb:
> Tilo R. schrieb:
>> (Das war nur als allgemeine Warnung gedacht, dein Beispiel ist ok.
>
> Und deshalb ist dein ganzes Post Unsinn.
sehe ich anders.
>
> Es ist normal dass man Pointer auf NULL testet bevor man drauf zugreift.
Richtig, ich habe nichts gegenteiliges behauptet.

> Und die Reihenfolge ist eben genau festgelegt und kein Zufall und kein
> undefined behaviour.
Richtig, ich habe nichts gegenteiliges behauptet.

Tilo R. schrieb:
> Etwas ausprobieren ist keine valide Taktik in C
Das ist meine Kernaussage. Imho auch richtig, ich habe sie sogar 
begründet.

[Rbx (rcx)]

1. Klammereinsparung
2. Besser von außen sichtbar, außer man hat viel mit Lisp zu tun ;)

[Cyblord -. (cyblord)]

Tilo R. schrieb:
>> Etwas ausprobieren ist keine valide Taktik in C
> Das ist meine Kernaussage. Imho auch richtig, ich habe sie sogar
> begründet.

Testen auf etwas ist kein "ausprobieren".

Dein Post ist reine Klugscheißen zu einem Problem was es im zitierten 
Code nicht gibt.

[Harald K. (kirnbichler)]

Tilo R. schrieb:
> Ich gehe sogar davon aus, dass für genau diesen &&-Anwendungsfall
> die Compiler eine optimierte Implementierung haben.

Das ist die "short circuit evaluation", die gibt es genauso beim 
logischen Oder.

int *p;

p = NULL;

if (!p || *p)
{
}

Auch das stürzt nicht ab, weil die Auswertung des logischen Oder nach 
dem ersten zutreffenden Element (hier: !p) abgebrochen wird.

https://de.wikipedia.org/wiki/Kurzschlussauswertung
https://en.wikipedia.org/wiki/Short-circuit_evaluation

[Johann L. (gjlayde)]

Paar Anmerkungen zur Shortcut-Evaluation:

Wenn der zweite Teilausdruch in a && b keine Seiteneffekte hat, dann 
darf der Compiler (bzw. der von ihm erzeugte Code) den Ausdruck 
auswerten, falls günstig. Beispiel:

void fun (void);

void call_fun (int a)
{
    if (a >= 10 && a <= 20)
        fun();
}

wird mit avr-gcc zu:

call_fun:
        sbiw r24,10
        sbiw r24,11
        brsh .L1
        rjmp fun
.L1:    ret

Man kann also die Teilausdrücke nicht mehr bestimmten 
Instruktion(sfolg)en zuordnen.

Nochn Hinweis zu C++: Shortcut Evaluation wird nicht auf überladene 
Operatoren && und || angewandt.