[solved] auswertungsreihenfolge von ausdrücken

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.