Auswertungsreihenfolge bie return
-
Hallo liebe Forengemeinde,
ich habe eine ganz kurze Frage zur Auswertungsreihenfolge beim return-Befehl.return vec1.x == vec2.x && vec1.y == vec2.y;Wird immer alles, was rechts vom return steht ausgewertet, bevor die Funktion zurückkehrt oder gibt es Befehle, die eine geringere Priorität haben? Liegt die Priorität des == vor der des && und wo kann man diese Prioritäten nachlesen?
Danke für eure Hilfe
-
Kannst du z.B. hier nachlesen:
http://en.cppreference.com/w/cpp/language/operator_precedence
-
-
Die Auswertungsreihenfolge von Ausdrücken ist überall die gleiche, egal ob ein return davor steht oder nicht. Hier werden vec1.x und vec2.x in unbestimmter Reihenfolge ausgewertet, dann wird das Ergebnis mittels == verglichen. Wenn und nur wenn das Ergebnis wahr war, dann wird der zweite Ausdruck ausgewertet, in vergleichbarer Reihenfolge.
Stichworte um das zu verstehen:
- Operatorrangfolge (operator precedence)
- Sequencepunkte (sequence points)
- Kurzschlussauswertung (short-circuit evaluation)
-
Warum hat man eigentlich die Auswertungsreihenfolge für Parameter bei einem Funktionsaufruf nicht festgelegt? Hat es zum Beispiel irgendwelche Performance(?)-Vorteile, wenn sie nicht definiert ist? Kann ja eigentlich nur etwas verschnellert werden, das nicht definiert ist, oder?
Hätte man sie nicht für C++0x zusätzlich ergänzen können, falls es damals versäumt wurde? Oder welchen Grund hat der Verzicht auf diese Auswertungsreihenfolge?
-
Wenn du das im Detail wissen willst, wende dich an das ANSI und frag nach, warum die damals C so gebaut haben (davon hat C++ das geerbt). Meine Vermutung ist, dass damals verschiedene C-Implementationen existierten, von denen manche es sorum und andere es sorum machten.
Mit dem Aufkommen optimierender Compiler gibt es aber in der Tat gute Gründe, diese Dinge undefiniert zu lassen, in C++ noch mehr als in C. Stell dir vor, du bist Compilerbauer und schreibst einen Linkzeitoptimierer - da bist du wahrscheinlich ganz froh, wenn du dich um solche Dinge nicht kümmern musst. Und es ist ja nun wirklich nicht so, dass die Reihenfolge, in der Funktionsparameter ausgewertet werden, in der Praxis (in von geistig gesunden Menschen geschriebenem Code) oft einen Unterschied macht.
-
Nachgefragt... schrieb:
Warum hat man eigentlich die Auswertungsreihenfolge für Parameter bei einem Funktionsaufruf nicht festgelegt?
Weil nicht festgelegt ist, in welcher Reihenfolge die Parameter auf den Stack gepusht werden - in der Reihenfolge werden sie auch ausgewertet. Und welche Reihenfolge DAS dann ist, ist so Compilerbauerlowlevel, dass man es wohl nicht sinnvoll festlegen kann, ohne den Compilerbauer arg einzuschränken.
-
Ohne Not macht man besser keine solchen Ausdrücke im return. Stattdessen empfiehlt sich eine lokale Variable int rtn mit einem return rtn;
Kann man dann vor dem return überprüfen, ob alles wie gewünscht gelaufen ist. Jedenfalls sollte man sich nie von einem bestimmten Compiler abhängig machen!
-
berniebutt schrieb:
Ohne Not macht man besser keine solchen Ausdrücke im return. Stattdessen empfiehlt sich eine lokale Variable int rtn mit einem return rtn;
Schlechter Tipp.
berniebutt schrieb:
Kann man dann vor dem return überprüfen, ob alles wie gewünscht gelaufen ist. Jedenfalls sollte man sich nie von einem bestimmten Compiler abhängig machen!
Nenne mir einen Fall, wo
int rtn=...; return rtn;sicherer ist als
return ...;Und rtn ist kein idealer Name.
-
Danke für eure Antworten. Zu berniebutt kann ich nur sagen, dass ich mal iwo gelesen habe, dass es in diesem Fall besser ist, auf die lokale Variable zu verzichten. Ist schließlich eine Operation mehr und mehr Speicher wird benötigt...
-
schrieb:
Ist schließlich eine Operation mehr und mehr Speicher wird benötigt...
Nö. Das optimiert der Compiler alles weg.
-
Der Returnwert einer Funktion ist ein festgelegter Datentyp, z.B ein int, ein Zeiger, oder eine Struktur. Deshalb führe ich wenn zweckmässig eine lokale Grösse für diesen Datentyp ein, die ich in der Funktion sicher prüfen kann, wo sie bestimmt wird. Jedenfalls übergebe ich im return ungarn mir unklare Ausdrücke.
Mag sein, dass dieser Vorschlag nicht jedem gefällt. Kostet aber kaum Performance und Speicherbedarf. Der Fragesteller wusste nicht, wie der Ausdruck abgearbeitet wird und ob das wie sogar compilerabhängig sein kann.
Mein bewährter Weg: Alle Funktionalität geprüft in der Funktion erledigen und für einen eindeutigen sicheren Rückgabewert sorgen. Wenn das in Ordnung ist, kann man die Internas der Funktion für eine Weile vergessen!
Idealer Name rtn? Mir egal, da bin ich schreibfaul! Wäre nach ungarischer Notation intReturn besser??
-
berniebutt schrieb:
Der Fragesteller wusste nicht, wie der Ausdruck abgearbeitet wird und ob das wie sogar compilerabhängig sein kann.
Ob der Ausdruck in einem return-Statement oder auf der rechten Seite einer Zuweisung steht, spielt doch dafür keine Rolle. Er weiß doch dann so oder so nicht, wie er abgearbeitet wird.
Davon abgesehenn ist die richtige Reaktion auf die Feststellung, dass man etwas nicht weiß, dass man es nachschlägt und lernt. Insbesondere wenn es absolut elementare Grundlagen sind. Ansonsten gibt es auch einfachere Sprachen wie Visual Basic, nicht jeder muss C++ schreiben.
-
berniebutt schrieb:
Der Returnwert einer Funktion ist ein festgelegter Datentyp, z.B ein int, ein Zeiger, oder eine Struktur. Deshalb führe ich wenn zweckmässig eine lokale Grösse für diesen Datentyp ein, die ich in der Funktion sicher prüfen kann, wo sie bestimmt wird. Jedenfalls übergebe ich im return ungarn mir unklare Ausdrücke.
Mag sein, dass dieser Vorschlag nicht jedem gefällt. Kostet aber kaum Performance und Speicherbedarf. Der Fragesteller wusste nicht, wie der Ausdruck abgearbeitet wird und ob das wie sogar compilerabhängig sein kann.
Mein bewährter Weg: Alle Funktionalität geprüft in der Funktion erledigen und für einen eindeutigen sicheren Rückgabewert sorgen. Wenn das in Ordnung ist, kann man die Internas der Funktion für eine Weile vergessen!
Idealer Name rtn? Mir egal, da bin ich schreibfaul! Wäre nach ungarischer Notation intReturn besser??
Das klingt etwas zu stark nach C des vergangenen Jahrhunderts.
-
volkard schrieb:
Das klingt etwas zu stark nach C des vergangenen Jahrhunderts.
Vergangenes Jahrhundert? Da hat man doch mit Assembler, ALGOL, FORTRAN, PL1 ... und auch C auf Dampfrechnern herumgeturnt - Igitt! Wegen hier kritisiertem Ansatz zur Steinzeitprogrammierung kein Thema für mich. Ist zu einfach und nachlesbar. Wieso dann solche Fragen, wenn C++ und OOP alles so leicht macht? daddeldu! :p
-
Welcher Wert zurückgegeben wird kann man im Debugger auch ohne Hilfsvariable nachgucken.
"rtn" als Name ist schlecht, weils total unüblich ist, nicht aussprechbar und nicht sprechend.
Wenn schon nen nichtssagenden Namen, dann wenigstens sowas wie "rc" oder "value".
-
hustbaer schrieb:
Wenn schon nen nichtssagenden Namen, dann wenigstens sowas wie "rc" oder "value".
rc habe ich noch nie gesehen. Wofuer steht das?
val, ret, res - sind die Sachen die ich frueher oefters gesehen habe.
-
Hm. Dann habe ich die Häufigkeit/Geläufigkeit von "rc" wohl etwas überbewertet
"rc" steht für "return code".Verwende ich auch nur für Fälle wo es eben ein "return code" ist, also ein success/error Code o.ä.
Wenns dagegen ein anderer Wert ist (String-Länge, Koordinate, Anzahl von irgendwas etc.) ist "rc" natürlich auch nicht gut.
-
also rtn ist schlecht, weil es in modernem Spaß-C rtrn heißen müßte (Einfach alle Vokale weglassen! Das gibt wenigstens eine Fehlererkennungshilfe.) Und weil man ja überhaupt keinen return returnen will ist es oberschlecht. Auch vom Sinn her nicht erschließbar. Oder nennt Ihr Eure Variablen nach Schlüsselwörtern, die gerade irgendwas mit dem Zweck zu tun haben? fr statt i und whl statt isRunning? Aber schön traditionell auf drei Zeichen pro Bedeutungsinhalt gekürzt. Helau.
Sondern erträglich wären einen vl oder rtrnvl oder ein rslt. Ach, dann kann man das rslt doch gleich auch result nennen. Schade, daß man das überhaupt noch sagen muß.
-
result nehm ich manchmal dafür.
hustbaer schrieb:
Welcher Wert zurückgegeben wird kann man im Debugger auch ohne Hilfsvariable nachgucken.
In welchem Debugger und wie? Beim MSVC geht es m.W. nicht. Ich bin jemand, der sich davon nicht den Stil diktieren lässt, aber einige Kollegen definieren genau deshalb grundsätzlich Variablen, die sie dann zurückgeben.
-
Bashar schrieb:
In welchem Debugger und wie? Beim MSVC geht es m.W. nicht.
Sobald die Funktion verlassen wurde stehen im MSVC bei den "Autos" die Werte, die die gerade aufgerufenen Funktionen zurückgegeben haben.
