Wahrscheinlich ist die Frage nicht so einfach zu beantworten, da es Compilerabhängig ist. Ausser es stünde etwas im Standard darüber, aber das würde mich etwas erstaunen. Die Problemstellung ist ganz einfach:

(VarA * VarB) / VarC;

Gibt es eine Garantie, dass hier zuerst die Multiplikation ausgeführt wird?
Bzw. gilt das auch umgekehrt:

VarA * (VarB / VarC);

Also das hier zuerst die Division ausgeführt wird?

Mathematisch macht es ja keinen Unterschied. Da wir aber in der Praxis mit begrenzten Datentypen arbeiten, macht es hier leider schon etwas aus. Wie ist das geregelt und wenn es Compiler abhängig ist, weiss jemand wie es beim MSVC geregelt ist? (2005 aufwärts)

Grüssli

Sollte alles gleich rangig sein bzw. ist alles aufgelöst, wird von link nach rechts gerechnet.
So sollte es auch der Compiler tun.

Gruß Tobi.

mit klammern ist aber gewärleistet was zuerst berechnet wird

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

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

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!

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

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

(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).

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: 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

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.