Überladen nur mit verschiedenem Rückgabewert
-
Hallo
Ich würde gerne eine Funktion nur im Rückgabewert überladen:
void set_a(double a); bool set_a(double a);damit, wenn ich es mal brauchen sollte, nachprüfen kann ob die set_ Übergabe bei komplizierten Datentypen erfolgreich war und somit keine defekten Daten vorliegen.
Warum ist so etwas nicht erlaubt?
In meinen Augen (als Anfänger) macht es Sinn. Wie ist es im Allgemeinen?
-
überladung_ schrieb:
Ich würde gerne eine Funktion nur im Rückgabewert überladen:
Warum ist so etwas nicht erlaubt?Das hatten wir heute schonmal :P.
Das ist einfach deswegen nicht möglich, weil der Rückgabetyp (und z.B. auch die Parameternamen) nicht zur Signatur einer Funktion gehört.Eine Funktion kennzeichnet sich "nur" durch ihren Namen und den Parameterdatentypen, also z.B. so:
function(int,float,double); // Eine Funktion namens "function" die 3 Parameter, vom Typ int, float und double, erwartet ... Es ist nicht nötig mehr zu wissen, um eine Funktion benutzen zu können.hoff das hilft dir weiter
-
Weil der Übersetzer manchmal nicht entscheiden könnte, welche „Überladung“ die richtige wäre. Das hat zumindest einmal jemand gesagt, und eigentlich stimmt das auch.
Allerdings finde ich, dass man das schon irgendwie hinbiegen und festlegen könnte, vielleicht gibt es das ja irgendwann einmal.
-
Wie Dweb gesagt hat, es ist konzeptionell so, dass der Rückgabewert nicht zu Signatur gehört. Es gibt durchaus Sprachen die es anderes definieren. Als Konsequenz muss mal halt ein Funktion über ein Zuweisung, Typecast, As-Operator, etc helfen, die Eindeutigkeit wiederherzustellen.
-
überladung_ schrieb:
damit, wenn ich es mal brauchen sollte, nachprüfen kann ob die set_ Übergabe bei komplizierten Datentypen erfolgreich war und somit keine defekten Daten vorliegen.
Dafür gibt es Exceptions!
-
Mach doch einfach mit Rückgabewert. Juckt doch niemand wenn Du den nicht immer verwendest.
rya.
-
Mit Templates ginge es.
-
Scorcher24 schrieb:
Mach doch einfach mit Rückgabewert. Juckt doch niemand wenn Du den nicht immer verwendest.
rya.Genau. Wir sind doch hier nicht bei Basic oder Pascal, wo wir noch die schwere Wahl zu treffen hatten, ob wir nun eine Funktion oder eine Prozedur schreiben wollten.
-
Scorcher24 schrieb:
Mach doch einfach mit Rückgabewert. Juckt doch niemand wenn Du den nicht immer verwendest.
Das find ich nicht gut, ist nämlich nicht Sinn der Sache. Schließlich liefert eine Funktion ein Resultat, um damit weiterarbeiten zu können. Wenn das Resultat einer Funktion aber nie verarbeitet wird, dann sollte man auch kein Ergebnis zurückliefern.
-
Dweb schrieb:
Scorcher24 schrieb:
Mach doch einfach mit Rückgabewert. Juckt doch niemand wenn Du den nicht immer verwendest.
Das find ich nicht gut, ist nämlich nicht Sinn der Sache. Schließlich liefert eine Funktion ein Resultat, um damit weiterarbeiten zu können. Wenn das Resultat einer Funktion aber nie verarbeitet wird, dann sollte man auch kein Ergebnis zurückliefern.
Wenn es aber nur manchmal verwendet wird? Hui...
Und keine Sorge, wenn es nicht weiterverwendet wird, spart der Compiler auch die nötigen Assembler-Befehle zur Rückgabe. Ganz brav.
MfG SideWinder
-
Dweb schrieb:
Scorcher24 schrieb:
Mach doch einfach mit Rückgabewert. Juckt doch niemand wenn Du den nicht immer verwendest.
Das find ich nicht gut, ist nämlich nicht Sinn der Sache. Schließlich liefert eine Funktion ein Resultat, um damit weiterarbeiten zu können. Wenn das Resultat einer Funktion aber nie verarbeitet wird, dann sollte man auch kein Ergebnis zurückliefern.
Das ist es doch aber, was überladung_ will. Eine Funktion, deren Rückgabewert er nur im Einzelfall auswertet. Ob man das nun durch templates, Überladung oder sontwas lösen will oder in einer Funktion, ist doch letztlich egal.
-
Dweb schrieb:
Scorcher24 schrieb:
Mach doch einfach mit Rückgabewert. Juckt doch niemand wenn Du den nicht immer verwendest.
Das find ich nicht gut, ist nämlich nicht Sinn der Sache. Schließlich liefert eine Funktion ein Resultat, um damit weiterarbeiten zu können. Wenn das Resultat einer Funktion aber nie verarbeitet wird, dann sollte man auch kein Ergebnis zurückliefern.
Stört ja nicht. So lange der Returnwert billig zu kopieren ist und "gratis" (oder fast gratis) in der Funktion zu ermitteln ist, wäre es fast schon ein Verbrechen ihn wegzulassen.
-
SideWinder schrieb:
Und keine Sorge, wenn es nicht weiterverwendet wird, spart der Compiler auch die nötigen Assembler-Befehle zur Rückgabe. Ganz brav.
Wenn es wirklich so ist, dann wäre mein Problem ja gelöst und ich könnte nur mit einer Funktion auskommen. Kennt sich da noch jemand damit aus? Ich verwende immer ziemlich neue Compiler. VC10 und GCC 4.5
-
überladung_ schrieb:
SideWinder schrieb:
Und keine Sorge, wenn es nicht weiterverwendet wird, spart der Compiler auch die nötigen Assembler-Befehle zur Rückgabe. Ganz brav.
Wenn es wirklich so ist, dann wäre mein Problem ja gelöst und ich könnte nur mit einer Funktion auskommen. Kennt sich da noch jemand damit aus? Ich verwende immer ziemlich neue Compiler. VC10 und GCC 4.5
Auch wenn es nicht so wäre, würde es doch in der Praxis in den meisten Fällen nichts ausmachen, denke ich. Oder wird deine Funktion in Schleifen ein paar Millionen mal ausgeführt und du kämpfst um jede Nanosekunde?
-
Und selbst wenn es zeitkritisch wäre: Es wird wegoptimiert. Was für Anweisungen sollte der Compiler denn generieren wenn der Rückgabewert nicht gebraucht wird? Einfach den Wert an eine leere Speicherstelle kopieren? Wenn ja, an welche? Es gibt einfach nichts was da überhaupt zu tun wäre.
-
SeppJ schrieb:
Und selbst wenn es zeitkritisch wäre: Es wird wegoptimiert. Was für Anweisungen sollte der Compiler denn generieren wenn der Rückgabewert nicht gebraucht wird? Einfach den Wert an eine leere Speicherstelle kopieren? Wenn ja, an welche? Es gibt einfach nichts was da überhaupt zu tun wäre.
Das stimmt so nicht ganz.
Bei Integers/Bools stimmt es wohl für die meisten Compiler, da "einfache" Rückgabewerte meist über ein Register gemacht werden.Rückgabewerte die nicht mehr in einem Register Platz haben werden allerdings auch bei Nicht-Verwendung konstruiert und wieder zerstört.
