if und UND-verknüpfte Bedignungen

Kannst Du ruhig hintereinander schreiben. Da von links nach rechts 
abgearbeitet wird, und bei dem ersten false eh abgebrochen wird.
Um Rechenzeit zu sparen am besten die Bedingungen die am 
häufigsten/schnellsten false liefern ganz nach links schreiben.

user schrieb:
> in C ist die Auswertungsreihenfolge der Argumente undefiniert

In C ist die Reihenfolge definiert. Grob gesagt: sie erfolgt immer 
links-nach-rechts ausser bei:

1

* Operationen (! ~ ++ --)

2

* ?:

3

* Zuweisung (= += -= *= /= %= &= ^= |= <<= >>=)

Mehr: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Blub schrieb:

> Was ist denn besser?

Übrigens kann man auch das Ergebnis von boolschen Operatoren in einer 
Variablen zwischenspeichern, wenn das ggf. die Lesbarkeit erhöht.

1

  bool first_parameter_valid  = p1 >= 4 && p1 < 20;

2

  bool second_parameter_valid = p2 >= 3 && p2 < 99;

3

4

  if ( first_parameter_valid && second_parameter_valid )

5

    ...

mfg Torsten

Achim S. schrieb:

> das erhöht aber kaum die Lesbarkeit gegenüber

Achim, das war nur ein Beispiel! ;-)

Torsten R. schrieb:
> Übrigens kann man auch das Ergebnis von boolschen Operatoren in einer
> Variablen zwischenspeichern, wenn das ggf. die Lesbarkeit erhöht.

Dann fällt aber (zumindest teilweise) die genannte short-circuit
evaluation weg.  Bei deinen einfachen Variablenabfragen mag das
egal sein, aber wenn zwischendrin eine komplexere Funktion aufgerufen
wird, berechnest du ggf. ein Ergebnis, welches für die Katz' ist.

Noch schlimmer, das Ergebnis könnte undefiniert sein oder eine
Speicherschutzverletzung bringen.  Überleg' dir mal, wie du das
mit dem Zwischenspeichern in Variablen hier machst bzw. was dann
passiert:

1

   if (ptr != NULL && eval_data(ptr->data) != 42) {

2

      // …

3

   }

Danach weißt du, warum man eine wohldefinierte short-circuit
evaluation in einer Sprache braucht.  (Pascal hatte sie zumindest
im ersten Standard nicht, sondern hat es dem Compiler überlassen.
In der Folge musste man dann immer zweimal if verschachteln.)

Jörg W. schrieb:

> Überleg' dir mal, wie du das
> mit dem Zwischenspeichern in Variablen hier machst bzw. was dann
> passiert:
>
>

1

>    if (ptr != NULL && eval_data(ptr->data) != 42) {

2

>       // …

3

>    }

4

>

Na, der "übliche" Weg ist dann, den Ausdruck schrittweise zu entwickeln:

1

const bool data_exists = ptr != 0;

2

const bool not_42      = data_exists && eval_data(ptr->data) != 42;

versteht mich nicht falsch, ich sage nicht, dass diese der einzige, 
wahre Weg ist! Ich wollte nur darauf hinweisen, dass dies ein Mittel 
sein kann, die Lesbarkeit zur erhöhen (Zitat: "wenn das ggf. die 
Lesbarkeit erhöht.")

Und ja, natürlich muss man short circuit berücksichtigen. Das muss man 
aber auch, wenn man den gesamten Ausdruck in einem hinschreibt.

Torsten R. schrieb:
> const bool not_42      = data_exists && eval_data(ptr->data) != 42;

Das aber setzt zwingend funktionierende short-circuit evaluation 
voraus, sonst knallt's, wenn ptr dereferenziert wird, um "eval_data" 
aufzurufen.

Rufus Τ. F. schrieb:
> Torsten R. schrieb:
>> const bool not_42      = data_exists && eval_data(ptr->data) != 42;
>
> Das aber setzt zwingend funktionierende short-circuit evaluation
> voraus, sonst knallt's, wenn ptr dereferenziert wird, um "eval_data"
> aufzurufen.

Oh mann, ließt den hier niemand mehr, sondern stürzt sich nur noch auf 
das letzte Posting?

Sorry, aber ich bin jetzt raus.

Keine Ahnung, was "leßen" sein soll - aber in einer Diskussion, wo um 
die Notwendigkeit oder nicht-Existenz der "short circuit evaluation" 
gestritten wird ... nehme ich den Thread vermutlich anders wahr als Du.

Rufus Τ. F. schrieb:
> Keine Ahnung, was "leßen" sein soll - aber in einer Diskussion, wo um
> die Notwendigkeit oder nicht-Existenz der "short circuit evaluation"
> gestritten wird ... nehme ich den Thread vermutlich anders wahr als Du.

Naja, so ganz nachvollziehen kann ich den Sinn deines Postings aber auch 
nicht. Nachdem Torsten meinte, dass man

1

   if (ptr != NULL && eval_data(ptr->data) != 42) {

z.B. auch durch

1

const bool data_exists = ptr != 0;

2

const bool not_42      = data_exists && eval_data(ptr->data) != 42;

ersetzen könnte, meinst du, dass das aber zwingend short-circuit 
evaluation benötigt. Das hat aber das Original auch schon. Außerdem 
hatte er das in seinem Posting schon selber explizit erwähnt:

Torsten R. schrieb:
> Und ja, natürlich muss man short circuit berücksichtigen. Das muss man
> aber auch, wenn man den gesamten Ausdruck in einem hinschreibt.

Dann sind wir ja immerhin alle einer Meinung. Ist doch gut so.

und hier das ärgerliche: beim überladenen && (in c++) gibt es wohl keine 
short-circuit evaluation.

Dumdi D. schrieb:
> und hier das ärgerliche: beim überladenen && (in c++) gibt es wohl keine
> short-circuit evaluation.

Wozu brauchst du das? Der Short-Circuit macht ja nur dann Sinn, wenn die
Operanden wie boolesche Werte behandelt werden können. Dann kannst du
für den neuen Datentyp aber auch einfach eine Konvertierungsfunktion
nach bool (operator bool()) schreiben und die normale &&-Operation mit
Short-Circuit verwenden.

Oder nimm Haskell ;-)

Da wird defaultmäßig lazy evaluiert, was das Short-Circuiting innerhalb
einer selbstgeschriebenen Funktion automatisch nach außen trägt. Solche
Funktonen wie && und || sind dort überhaupt nichts Spezielles und auch
nicht auf boolesche Werte beschränkt.