[solved] auswertungsreihenfolge von ausdrücken

Ergänzung zu Bashar:
Was da noch dazukommt ist, dass die rechtsseitigen Ausdrücke u.U. gar nicht ausgewertet werden (wenn das Ergebnis des gesamten Ausdrucks bereits durch die Auswertung des linksseitigen feststeht). Bsp:

// func() wird hier nicht ausgeführt
true || func()

// dito
false && func()

// func1() wird hier nicht ausgeführt
false ? func1() : func2()

// func2() wird hier nicht ausgeführt
true ? func1() : func2()

iko79

jo, is mir auch bekannt, danke ^^ aber ich dachte eben es wäre genau aus dem grund auch oft gefährlich sowas zu schreiben, da man net wissen kann was zuerst dran kommt.

Bashar

iko79 schrieb:

hab btw. grad das hier gefunden -- scheint also doch für alle operatoren definiert zu sein?

Da steht, dass es undefiniert ist Die Assoziativität hat mit der Auswertungsreihenfolge nichts zu tun. Wenn du z.B. sowas hast:

a() + b() + c()

bedeutet das zwar wegen der Linksassoziativität

(a() + b()) + c()

aber niemand verbietet, dass beispielsweise zuerst c aufgerufen wird.

iko79

Bashar schrieb:

Die Assoziativität hat mit der Auswertungsreihenfolge nichts zu tun.

ACHSOOH!! hab das in einen topf geworfen, stimmt. deswegen hab i auch das problem beim angeführten beispiel erst net verstanden...

danke!!

Tim schrieb:

// func1() wird hier nicht ausgeführt
false ? func1() : func2()
// func2() wird hier nicht ausgeführt
true ? func1() : func2()

wundert das jemanden?

iko79

achso, moment nochmal....

Tim schrieb:

// func() wird hier nicht ausgeführt
true || func()

// dito
false && func()

DAS wundert mich allerdings schon. davon kann man doch nicht ausgehen, oder?

LordJaxom

iko79 schrieb:

DAS wundert mich allerdings schon. davon kann man doch nicht ausgehen, oder?

Doch. Nennt sich Kurzschlussoperator. Ist in vielen Sprachen so, und bei manchen Sprachen die sowas nicht kennen tendiert man sogar dazu Kurzschlussoperatoren nachzurüsten.

EDIT:
Gerade bei Scriptsprachen findet man gern Sachen wie

do_something() || die("Fehler im Programm");

Wäre dann sehr schlecht, wenn das Programm immer stirbt, egal ob do_something() gut oder schlecht ausgeht

iko79

allerdings wär das schlecht
kurzschlussoperatoren, soso... wieder was gelernt. das lässt sich ausserdem leichter googeln ^^ naja, dass irgendeine möglichkeit bestehen MUSS sich darauf verlassen zu können hab i mir fast gedacht -- immerhin stammt mein ursprünglicher codeschnippsel aus der ACE API und nachdem die iridium-satelliten net dauernd vom himmel fallen scheint die zu funktionieren.

i glaub, jetzt bin i fürs erste mal zufrieden gestellt ^^ danke nochmal an alle!

pointercrash**

Tim schrieb:

true || func()

Aber true und false sind nur Dein Behelf oder ist das in C definiert?
Sieht nämlich sehr Pascal- like aus

Bashar schrieb:

aber niemand verbietet, dass beispielsweise zuerst c aufgerufen wird.

Eine Stolperfalle, an die ich ungute Erinnerungen habe: Ein Regler, der mit großen Zahlen hantiert, funktioniert im Original auf einem embedded Pascal bestens, die C- Portierung liefert immer wieder mal Blödsinn und funktioniert nur, wenn ich alle Optimierungen abschalte - ein völlig unsystematisches Bild.
Die Lösung, nach der ich lange gesucht habe: Der Compiler konnte beim Optimieren Umspeicherungen sparen und hat ein wenig umgestellt, dadurch sind Teilergebnisse entstanden, die den Wertebereich von int16 überschritten haben . In dem Fall hat letztendlich Klammerung geholfen, da hat der Optimierer nichts mehr zerrissen .

Wobei sich mir im Nachhinen die Frage stellt, ob das generell so ist, daß der Compiler die Klammerung peinlichst beachten muß - weiß das jemand?

pointercrash() schrieb:

Tim schrieb:
true || func()
Aber true und false sind nur Dein Behelf oder ist das in C definiert?
Sieht nämlich sehr Pascal- like aus

Seit C99 gibts den Standardheader stdbool.h , da sind die beiden definiert (neben dem Makro bool für das neue Schlüsselwort _Bool ).

pointercrash**

Tim schrieb:

Seit C99 gibts den Standardheader stdbool.h , da sind die beiden definiert (neben dem Makro bool für das neue Schlüsselwort _Bool ).

Seltsam, ich hab' jetzt drei ziemlich aktuelle Compiler überprüft, alle kennen den Typen _Bool, aber keiner hat den Standardheader im Paket noch kann irgendeiner was mit true oder false anfangen. Sollte mir solcher Code unterkommen, wäre es probat, true und false einfach per #define auf 1 und 0 zu setzen oder siehst Du Probleme, außer daß es nicht groß geschrieben wäre ;)?

Du könntest zudem wissen, ob ein Optimierer in eine per Grouping Operator vorgegebene Auflösungsreihenfolge hineinfummeln darf

Bashar

pointercrash() schrieb:

Sollte mir solcher Code unterkommen, wäre es probat, true und false einfach per #define auf 1 und 0 zu setzen oder siehst Du Probleme, außer daß es nicht groß geschrieben wäre ;)?

auf _True und _False, die müssten existieren, wenn er _Bool kennt.

Du könntest zudem wissen, ob ein Optimierer in eine per Grouping Operator vorgegebene Auflösungsreihenfolge hineinfummeln darf

Was ist ein Grouping Operator? Falls du damit Klammern meinst (das sind keine Operatoren), nein, darf er nicht. Er darf die Teilausdrücke in beliebiger Reihenfolge auswerten, muss aber beim Zusammensetzen der Teilergebnisse natürlich die vorgegebene Struktur einhalten.

Swordfish

pointercrash() schrieb:

Seltsam, ich hab' jetzt drei ziemlich aktuelle Compiler überprüft, alle kennen den Typen _Bool, aber keiner hat den Standardheader im Paket noch kann irgendeiner was mit true oder false anfangen. Sollte mir solcher Code unterkommen, wäre es probat, true und false einfach per #define auf 1 und 0 zu setzen oder siehst Du Probleme, außer daß es nicht groß geschrieben wäre ;)?

laut IEEE 1003.1-2001 müsste ein <stdbool.h> so aussehen:

#ifndef __bool_true_false_are_defined

#define bool _Bool
#define true 1
#define false 0
#define __bool_true_false_are_defined 1

#endif /* __bool_true_false_are_defined */

greetz, Swordfish

pointercrash**

Bashar schrieb:

Was ist ein Grouping Operator? Falls du damit Klammern meinst (das sind keine Operatoren), nein, darf er nicht.

Danke für die Antwort, das ist jetzt klar. Aber Das mit dem Grouping Operator hab' ich mir nicht aus den Fingern gesogen, das stammt von hier http://www.cppreference.com/operator_precedence.html , guckst Du zweiten Tabelleneintrag .

Bashar schrieb:

auf _True und _False, die müssten existieren, wenn er _Bool kennt.

Nee, auch nicht, bei keinem. Ist kein Beinbruch, weil ich's nie vermißt habe, nur verblüffend. 99% ANSI- kompatibel sind dann doch nicht ganz ANSI.

Swordfish schrieb:

#define true 1
#define false 0

Danke, also hat mich meine Ahnung nicht getrogen

Bashar

pointercrash() schrieb:

Bashar schrieb:

Was ist ein Grouping Operator? Falls du damit Klammern meinst (das sind keine Operatoren), nein, darf er nicht.

Danke für die Antwort, das ist jetzt klar. Aber Das mit dem Grouping Operator hab' ich mir nicht aus den Fingern gesogen, das stammt von hier http://www.cppreference.com/operator_precedence.html, guckst Du zweiten Tabelleneintrag .

Aua. Ich gebe zu, dass ich zuerst auch dachte, mit () seien die Klammern gemeint (vor 15 Jahren ungefähr), aber damit ist natürlich wirklich der () Operator, also der Funktionsaufruf, gemeint.

pointercrash**

Bashar schrieb:

Aua. Ich gebe zu, dass ich zuerst auch dachte, mit () seien die Klammern gemeint (vor 15 Jahren ungefähr), aber damit ist natürlich wirklich der () Operator, also der Funktionsaufruf, gemeint.

Wirklich? Wenn Du das Beispiel anschaust

(a + b) / 4;

sind das wirklich nur Klammern und kein function call. Oder ist das cppreference etwas unpräzise oder schreibe ich uns jetzt in die totale Konfusion

Bashar

pointercrash() schrieb:

Oder ist das cppreference etwas unpräzise

Ja, um nicht zu sagen falsch. Das Beispiel beim Assignment-Operator ist auch falsch, man sieht dort eine Initialisierung, keine Zuweisung. Wahrscheinlich sollte man sich einfach von dem Domainnamen nicht blenden lassen.

nun wissen wir aber immer noch nicht, ob () ein operator ist oder nicht. ich bin ja der meinung, dass es keiner ist. aber meistens geht eine rechnung (a+b)/c anders aus als a+b/c, so dass man den klammern einen gewissen 'operatoreffekt' nicht absprechen kann.