Hi,

Alsooo

Ich würde sagen, es kommt 38 raus

Rechnung:
12 + [ ((1+12) + 12) +1]

Klammern dienen natürlich ausschließlich der Veranschaulichung (dank kommutativität).

++x und x++ werden i.d.R. bei Schleifen verwendet.

++x heißt: Erst hochzählen, dann weitermachen (bzw. schleife durchlaufen)
x++ heißt: erst einmal durchgehen, danach hochzählen.

Ist aber bei dir vollkommen egal, selbst wenn du es teilweise andersrum machst, würde bei diesem Beispiel das selbe Ergebnis rauskommen.

Wenns falsch ist verbessert mich bitte Aber mein Gedächnis drängt mir das gerade auf

ich kann nur für Java sprechen, aber ich schätz mal, dass es bei c++ ähnlich ist:
Bei den Schleifen passiert das gleiche wie auch wenn man die Operatoren normal verwendet. ++x bedeutet x wird um 1 erhöht und dann wird der rest der aktuellen Operation durchgeführt. x++ bedeutet hingegen, dass erst die restliche Operationen durchgeführt werden und erst danach wird x um 1 erhöht. Das bedeutet, wenn ich zuweisungen im gleichen Schritt mache, bleibt das x++ völlig ohne Wirkung...
Beispiel:

hier ist am Ende die Ausgabe trotzdem 5 obwohl zwischendrin ja x++ vorkommt. Das liegt daran, dass in der 2. Zeile dem x der alte x-Wert zugewiesen wird und erst danach das jetzt alte x erhöht wird, was keine auswirkungen mehr hat

daher hat in
"x += ++x+x++;" das letzt ++ keine Auswirkung, man kann es also direkt weglassen... Beim Rest würd ich aber trotzdem sagen, dass 38 herauskommt. Denn zu allererst wird durch ++x das x um eins erhöht. Dies gilt aber für beide x auf der rechten Seite. Daher haben wir 13 + 13 und dann nochmal + 12 durch das +=
Gut um am Ende wird das ergebnis noch verdoppelt, aber das is irgendwie nicht so spannend
Das deckt sich auch alles mit kurzen Tests, die ich schnell in Java durchgeführt hab... Jetzt muss das nurnoch alles auch auf C/C++ zutreffen (oder um was es hier auch immer geht)

Edit:

Soweit bin ich auch gekommen. Aber das ganze mit VisualStudio in C++ kompiliert ergibt dann 80 und da komm ich nicht ganz dahinter.

Ok, wenn bei dir da 80 rauskommt, ist es wohl wirklich anders in C++

bzzz auch grad gemerkt, etwas vertan

In java würde bei dir 38 bzw. 38 + 38 = 76 rauskommen (wie Rondrer schon erwähnt hat).
Wäre aber mal sehr interessant wie C++ das macht.

ich glaub ich bin der Sache auf der Spur Hab mal mit dem GCC-C++ compiler ein paar tests gemacht...
erstmal ist ja

nichts anderes als

ich kanns nur damit besser erklären.
Es scheint so als würde das eine ++x alle 3 x um eins erhöhen. also sind wir bei 13+13+13.
dann haben wir nurnoch das x++ was einfach das x nochmal um 1 erhöht, nachdem der komplette ausdruck ausgewertet ist. Dann kommen wir auf die 40

bis jetzt hat die theorie auch den verschiedensten Tests standgehalten

Also ++x heißt pre increment, x++ post increment und sind unäre Operatoren. Der Unterschied von beiden lässt sich am besten durch eine Funktion erklären:



Die Operatoren macht also zwei Sachen: Erstens verändert sie den Wert von x und zweitens geben sie einen Wert zurück. preIncrement gibt den neuen Wert von x zurück (also mit dem dazuaddierten) und postIncrement den ursprünglichen Wert (ohne den dazuaddierten).
Bei deiner Rechnung wird x mit 12 initialisiert. Dann gucken wir uns den Ausdruck mal an:

x += ++x+x++;
ist äquivalent zu:
x =x+ ++x+x++;

Man kann erkennen dass hier die Auswertungsreihenfolge eine Rolle spielt. Die meisten C-Compiler werten glaube ich von rechts nach links aus (ist soweit ich weiß duch den ANSI-Standard nicht festgelegt und darf von jedem Compiler gemacht werden wie er will).Da die Addition kommutativ ist, ist es aus mathematischen Gesichtspunkten ja auch egal, das Problem hier ist nur das x während der Berechnung verändert wird und deswegen die Reihenfolge nicht egal ist. Von rechts nach links sähe das dann so aus:


Wenn der Compiler von Links nach rechts auswertet (ich glaube Java macht das so), kommt folgendes dabei raus:

Wie man sieht, sollte man mit destruktiven Operatoren in komplexeren Ausdrücken höllisch aufpassen.

nee, das stimmt so nicht. Die Compiler werten nicht streng der Reihenfolge nach aus (bei unterschiedlichen Operatoren). Sie beherrschen ja auch "Punkt-vor-Strich".
Von den hier benutzen Operatoren hat der Post-Inrement die niedrigste Priorität, wird also immer als letztes ausgewertet. Das merkt man daran, dass wenn man in dem Ausdruck das "++" am Ende einfach weglässt, kommt als Ergebnis 39 raus. Man kann auch die Reihenfolge komplett verändern, ohne dass sich daran etwas ändert:

liefert das gleiche Ergebnis wie


und auch hier, kann ich den Post-increment Operator weglassen und es liefert 39

Sagen wir, "nee, das stimmt nicht so ganz". Ich hab nach dem verfassen des Beitrages selber auch nochmal recherchiert, in C haben preInkrement und postInkrement tatsächlich eine unterschiedliche Priorität, die muss der Compiler natürlich berücksichtigen. Mir war das aber entfallen. Bei Java allerdings nicht und er versucht wirklich von Links nach rechts auszuwerten, siehe hier, also stimmt der Teil schonmal (auch die 38, habs ausprobiert :D). In C dachte ich wäre es ebenfalls so, allerdings haben postfix-Operatoren eine höhere Priorität. Dadurch ist der Ausdruck natürlich eindeutig und muss immer so abgearbeitet werden, wie ich es beschrieben habe. Andere Auswertungen würden den C-Standard verletzen und wären illegal.
Trotzdem bleiben in Ausdrücken mit Operatoren gleicher Priorität dem Compiler manchmal Wahlmöglichkeiten. Beim GCC habe ich es grade ausprobiert, er wertet zumindest bei Funktionsaufrufen wohl von rechts nach links aus: