[solved] Werden Klammern berücksichtigt oder wegoptimiert?

Skym0sh0

meiner meinung nach geht der compiler einfach alles von links nach rechts durch

mit klammern ist aber gewärleistet was zuerst berechnet wird

uhsuhz

In C++ haben alle operatoren Prioritäten, und so haben klammern einen höheren Stellenwert als * oder /, die wiederum einen höheren Stellenwert als + und - haben, und so müsste dein kompiler eigentlich auch zu erst die klammern ausrechnen, oder?

TheBernd

Das hängt ganz vom Compiler und seinen operator prezedenzen ab. (zb. MSC++ vs. Open Watcom)
Teilweise ist es sogar nicht mal definiert z.b. wenn zwei operator dieselbe prezedenz haben.
Mehrdeutig: stupidratio = value / ++value

Daumen regel, vor allem für portablen Code ist: Immer Klammern verwenden.

Dravere

Also mit Vermutungen kann ich nichts anfangen, trotzdem danke Skym0sh0 und uhsuhz.
Ich hoffe mal T0bi weiss wovon er spricht.

Ich habe zudem nochmals im Buch "Die C++ Programmiersprache" nachgeschaut und bei der Reihenfolge der Operatoren finde ich die normalen Klammern einfach nicht. Das, was am nächsten kommen würde, ist folgendes:
typ (ausdruckliste)
Aber für mich wäre da eher sowas gemeint:
int(6)

Und im restlichen Teil des Kapitels finde ich auch nichts explizites dazu. Daher meine Unsicherheit und auch weil es um Millionenbeträge geht und ich nicht verantwortlich sein möchte

@TheBernd,
Das mit dem ++value ist mir bekannt. Aber darum geht es ja nicht. Es geht darum, ob bei meinem Beispiel oben die Klammern berücksichtigt werden oder nicht.

Kann mich sonst noch wer absichern?
Am besten wäre ja ein Verweis auf den Standard oder sowas.

Grüssli

Vartus

siehe operator prcedence

Dravere

Ok, ich habe es hier gerade auch gefunden:
http://www.cplusplus.com/doc/tutorial/operators.html

Es sind zwar keine offiziellen Dokumente, aber was solls. Ich muss mich wohl darauf verlassen und werde zur Sicherheit auch noch ein paar Tests durchführen um gaaaaaaaaaannnnz sicher zu gehen

Ich hoffe die Compiler halten sich in dem Punkt explizit an den Standard.

Grüssli und Danke!

minhen

Der Standard schreibt eine Präzedenz der Operatoren nicht explizit vor, sondern sagt nur, dass diese aus der Syntax-Definition folgt. Das heißt auch ziemlich direkt, dass deine Klammerung immer berücksichtigt wird.

hustbaer

Wenn du konkret was zu dem Thema wissen willst kannst du da nachgucken: http://msdn.microsoft.com/en-us/library/aa289157(vs.71).aspx

Kurz: MSVC macht so ziemlich was er will, solange man es ihm nicht mit entsprechenden Switches verbietet, was netterweise auch möglich ist.

Wer ja auch schlimm, wenn man sich nicht mla auf die Klammersetzung verlassen könnte.

Dravere

hustbaer schrieb:

Wenn du konkret was zu dem Thema wissen willst kannst du da nachgucken: http://msdn.microsoft.com/en-us/library/aa289157(vs.71).aspx

Kurz: MSVC macht so ziemlich was er will, solange man es ihm nicht mit entsprechenden Switches verbietet, was netterweise auch möglich ist.

Da geht es aber um Floating-Point Optimization. Ich persönlich brauche in dem Fall allerdings integrale Typen. Gibt es dazu auch einen Artikel?

Aber ganz interessant und gut zu wissen, merk ich mir, wenn ich das nächste Mal mit floats und doubles arbeite. Danke!

Grüssli

camper

Dravere schrieb:

(VarA * VarB) / VarC;

Der Standard schreibt hier ein ganz bestimmtes Verhalten vor, d.h. einen bestimmten Wert für den Ausdruck, für gegebene VarA,VarB,VarC sofern die besonderen Werte nicht zu undefiniertem Verhalten (wegen Überlauf oder Division durch 0) führen. Er schreibt (im Wesentlichen) nicht vor, wie eine Implementation zu diesem Wert kommen kann. Falls Var*(VarB/VarC) zum gleichen Ergebnis kommen sollte (tut es nicht), wäre es eine zulässige Transformation. Es gibt ein etwas interessanteres Beispiel direkt im Standard (1.9/15):

int a, b;
/*...*/
a = a + 32760 + b + 5;

Eine Implementation darf dies im Allgemeinen nicht umschreiben als

a = ((a + 32765) + b); // oder
a = (a + (b + 32765));

Da beide Ausdrücke für bestimmte Werte (z.B. a = –32754, b = –15 und 16-bit Integer) zu Überläufen führen würden, während der originale Ausdruck das nicht tut (für diese Werte). Etwas anderes gilt dagegen, falls diese spezielle Implementation eine ist, für die Überläufe irrelevant und reversibel sind (2er-Komplement).

hustbaer

@Dravere: ich habe angenommen dass du von floating point Berechnungen sprichst, da die Frage bei Integer (für mich) sowas von klar ist

Wie camper schon schrieb kannst du dich bei Integer auf jeden Fall auf das Ergebnis verlassen, also dass es dem entspricht was der Standard vorgibt. Und der gibt vor dass Klammern bei der Auswertung von Ausdrücken berücksichtigt werden.

Der Compiler darf, wie camper auch schon schrieb, trotzdem ein Programm erzeugen welches anders rechnet als das was du hinschreibst, wenn garantiert ist dass das Ergebnis stimmt.

Der Compiler darf sogar viel viel mehr tun - wenn garantiert ist dass das "beobachtbare" Verhalten sich nicht ändert kann er im Prinzip tun was er will. z.B. ganze Berechnungen/Schleifen/... einfach wegoptimieren etc.

p.S.: was "beobachtbar" ist ist auch im Standard definiert

Dravere

hustbaer schrieb:

@Dravere: ich habe angenommen dass du von floating point Berechnungen sprichst, da die Frage bei Integer (für mich) sowas von klar ist

Weil es so klar ist, wird es wohl nirgends in meinen Büchern erwähnt, was mich aber genau misstrauisch gemacht hat
Wenn ich allerdings schaue, wie oft ich nun so Standard-Spezifische Fragen stelle, glaube ich so langsam, dass sich die Anschaffung des Standards als Buch wirklich lohnen würde

Danke für die Hilfe!

Grüssli

drakon

Dravere schrieb:

stelle, glaube ich so langsam, dass sich die Anschaffung des Standards als Buch wirklich lohnen würde

Das glaube ich kaum. Wenn du dann deine 1000 Seiten in der Hand hälst, biste eh nur deprimiert. - Lad doch lieber den Draft runter. Vor allem, weil du nächstes Jahr wahrscheinlich eh den neuen holen müsstest.