4. Frage zur Auswertungsreihenfolge von Operatoren in einem konkreten Fall

Frage zur Auswertungsreihenfolge von Operatoren in einem konkreten Fall

  • N

    Darüber hinaus gibt es wohl ein kleines Missverständnis bezüglich dem Begriff der Auswertungsreihenfolge.
    Bei so einem Ausdruck: a + b * c ist es natürlich klar, dass zuerst b * c multipliziert werden und dann a addiert. Aber hat man Funktionsaufrufe: a() + b() * c() ist es nicht spezifieziert in welcher Reihenfolge die Funktionen aufgerufen werden. Das meinte ich (und vermutlich andere) hauptsächlich mit Auswertungsreihenfolge.

    0
  • E

    Mach einfach keine so dämlichen Konstrukte wenn du nicht SeppJ's und Swordfish's code obfuscation contest beitreten willst.

    In-/Dekremente sind immer mit Vor- und Voraussicht zu benutzen.

    Aufgeteilt und eine Zeile mehr geschrieben kann dich vor überraschenden Ergebnissen bewahren.

    Ansonsten ist das eine ziemlich überflüssige, konstruierte Geschichte, die eigentlich Keinem hilft.
    Interessant wäre vielleicht wie das Ganze mit einem Präfix ausgehen würde.
    Bliebe aber immernoch eine ziemlich überflüssige, konstruierte Geschichte, die eigentlich Keinem hilft.

    0
  • Mod

    EOP schrieb:

    Mach einfach keine so dämlichen Konstrukte wenn du nicht SeppJ's und Swordfish's code obfuscation contest beitreten willst.

    In-/Dekremente sind immer mit Vor- und Voraussicht zu benutzen.

    Die Kurzschlussauswertung in Kombination mit Seiteneffekten auf der rechten Seite ist aber ein Klassiker der (nicht-obskuren) C-Programmierung. Das sollte man schon kennen und auch keine Scheu vor der Benutzung haben. Man kann auch sagen das muss man kennen, denn sonst kommt es schnell zu eben dem Fehler, vor dem du hier warnst. Aber wenn man es sowieso kennt, kann man es ja auch produktiv einsetzen 🙂 .

    0
  • E

    SeppJ schrieb:

    EOP schrieb:

    Mach einfach keine so dämlichen Konstrukte wenn du nicht SeppJ's und Swordfish's code obfuscation contest beitreten willst.

    In-/Dekremente sind immer mit Vor- und Voraussicht zu benutzen.

    Die Kurzschlussauswertung in Kombination mit Seiteneffekten auf der rechten Seite ist aber ein Klassiker der (nicht-obskuren) C-Programmierung. Das sollte man schon kennen und auch keine Scheu vor der Benutzung haben. Man kann auch sagen das muss man kennen, denn sonst kommt es schnell zu eben dem Fehler, vor dem du hier warnst. Aber wenn man es sowieso kennt, kann man es ja auch produktiv einsetzen 🙂 .

    Wieso bist du um 3 morgens nicht im Bett, wo du eigentlich hingehörst? 🙂

    EDIT:
    Und - natürlich benutze ich es auch. Ist ja eine der Sachen, die ich an C/C++ ziemlich cool finde.
    Aber nicht bei Konstrukten wie

    if( a < 1 && b < c++ || d > --c & f-- && ~g | --h ^ c )

    Muss nicht sein wenn du vorhersagbare Ergebnisse haben willst.

    0
  • Mod

    Klar, kann man's auch übertreiben.

    0
  • E

    4 morgens und SeppJ sitzt immernoch aufm Wachturm. Unglaublich.

    0
  • Mod

    EOP schrieb:

    4 morgens und SeppJ sitzt immernoch aufm Wachturm. Unglaublich.

    Zeit ist relativ.

    0
  • E

    SeppJ schrieb:

    Zeit ist relativ.

    Für mich anscheinend auch.

    0

  • EOP schrieb:

    Mach einfach keine so dämlichen Konstrukte wenn du nicht SeppJ's und Swordfish's code obfuscation contest beitreten willst.

    Siehst Sepp was wir angerichtet haben? EOP wird wohl alles obskur anmutende von nun an in die Obfuscation-Ecke stellen 😞

    0
  • L

    Möglicherweise hat es gerade bei mir *klick* gemacht, also hoffe ich, dass ihr mir bestätigen könnt, dass mein folgendes Gedankenspiel korrekt ist:

    Gegeben ist: 1 < 0 && 2 < a++

    Was macht C nun damit? Nun, zunächst mal halten wir fest, was C damit nicht macht:

    Compiler: "Dummdidumm was für ein schöner Morgen...oh was seh ich da? Ein Ausdruck, wie schön! Ich bin jetzt aber noch zu müde, mir sofort den ganzen Ausdruck anzusehen und in Gänze zu interpretieren. Also pick ich mir erstmal nur den Operanden mit der höchsten Priorität raus und guck mir den Rest später an. Na, dann komm her, kleiner Inkrement-Operator. Du zählst jetzt erstmal schön a um 1 hoch. Danke, jetzt darfst du dich wieder setzen. Sodelle, was haben wir noch? Aahhh, einen <-Operator, ein Klassiker! 1 < 0 ?? Unsinn! Setzen, sechs! *kopfschüttel* Wie gehts weiter? Hmm, ein &&-Operator...na, der dürfte von dem Quatsch, der da links von ihm veranstaltet wird aber gar nicht begeistert sein und bricht beleidigt den ganzen Ausdruck ab. Oh, hoppla, dann hätte ich dem Inkrement-Operator ja gar nicht sagen dürfen, dass er um 1 hochzählen soll...jetzt ist's zu spät...wie peinlich..."

    Ok, das macht C also nicht. Und was macht es nun wirklich? Folgendes:

    Compiler: "Dummdidumm was für ein schöner Morgen...oh was seh ich da? Ein Ausdruck, wie schön! Ich bin zwar noch nicht ganz wach, aber bevor ich hier irgendeinen peinlichen Unsinn anstelle, guck ich mir den Ausdruck lieber erstmal ganz genau von vorne bis hinten in seiner vollem Pracht an, um zu wissen, was der letztendlich im Schilde führt. Du brauchst gar nicht so eifrig zu winken, kleiner Inkrement-Operator. Ich hab dich schon gesehen und weiß, dass du die höchste Priorität hast, du kleiner Angeber. Aber ich guck mir erst noch deine Freunde an, was die so vorhaben. *guck* *amkopfkratz* *grübel* Aha, der &&-Operator wird, wenn ich den Code ausführe, wieder die beleidigte Leberwurst spielen und allen den Spaß versauen. *kopfschüttel* Sorry, kleiner Inkrement-Operator, du hast zwar die höhere Priorität, aber wenn hier eh gleich das Spielbrett vom Tisch gefegt wird, ist es auch überflüssig dich vorher noch a um 1 hochzählen zu lassen. Sei nicht traurig, morgen ist ein neuer Tag."

    Ist das so korrekt? Der Compiler analysiert erst den Gesamtausdruck und entscheidet dann, dass der Inkrement-Operator, obwohl seine Priorität höher ist als die des &&-Operators, nicht ausgeführt wird, da der &&-Operator das nachträglich als Fehler entlarfen würde?

    EOP schrieb:

    Mach einfach keine so dämlichen Konstrukte wenn du nicht SeppJ's und Swordfish's code obfuscation contest beitreten willst.

    In-/Dekremente sind immer mit Vor- und Voraussicht zu benutzen.

    Aufgeteilt und eine Zeile mehr geschrieben kann dich vor überraschenden Ergebnissen bewahren.

    Ansonsten ist das eine ziemlich überflüssige, konstruierte Geschichte, die eigentlich Keinem hilft.

    Da stimme ich dir voll und ganz zu. Ich selbst würde das auch so nicht schreiben. Ich will aber darauf vorbereitet sein, sowas in der anstehenden Klausur richtig lösen zu können. In den vom gleichen Proffessor gestellten Übungen kam der In-/Dekrement-Operator dran und sorgte bei den meisten für reichlich Verwirrung.

    EOP schrieb:

    Interessant wäre vielleicht wie das Ganze mit einem Präfix ausgehen würde.

    Jemand 'ne Idee?

    0

  • Laputzki schrieb:

    Ist das so korrekt? Der Compiler analysiert erst den Gesamtausdruck und entscheidet dann, dass der Inkrement-Operator, obwohl seine Priorität höher ist als die des &&-Operators, nicht ausgeführt wird, da der &&-Operator das nachträglich als Fehler entlarfen würde?

    Natürlich muss ein Compiler immer das gesamte Statement "ansehen". Bei deinem Beispiel 1 < 0 && 2 < a++ geht es aber nicht um ausführen oder nicht ausführen. Für 2 < a++ wird schlicht garkein Code erzeugt, weil 1 < 0 immer false ist.

    Laputzki schrieb:

    EOP schrieb:

    Interessant wäre vielleicht wie das Ganze mit einem Präfix ausgehen würde.

    Jemand 'ne Idee?

    *kopfkratz* was?

    0
  • E

    Laputzki, wenn du mit deinem Prof ebenfalls wie mit einem Vierjährigen redest, kriegst du auf jeden Fall einen Schein. Nur nicht den, den du erwartest. 😉

    0
Anmelden zum Antworten