|
Anzeige
|
C++: Variablenübergabe Funktion: In/Out oder In Out Seperat?
Gast
#6407280
Hey,
was macht mehr Sinn oder ist gängiger?
void foo(std::string& Input, std::string& Output){}
bool foo(std::string& In_Out){}
Bei zweiter Variante ist es doch üblich eine Rückgabe zu generieren,
damit ich nach Aufruf erkenne wann sich der Wert verändert hat!?
Gast
#6407286
Möglichkeit 3: Den String bzw. die String-ref als Rückgabewert. Und wie immer lautet die Antwort: Kann man so nicht sagen, kommt drauf an. Was macht die Funktion denn überhaupt mit dem String? Radio Eriwan sagt: Es kommt darauf an... Nämlich darauf, was das ganze überhaupt soll. Oliver
Gast
#6407306
Vielleicht könnt Ihr mir alle drei Anwendungsfälle mal beschreiben wann Ihr die einsetzen würdet :) Ich bin wirklicher Anfänger und möchte einfach den Unterschied und die Anwendung davon wissen
Gast
#6407321
Technokrat schrieb: > Hey, > > was macht mehr Sinn oder ist gängiger? > > void foo(std::string& Input, std::string& Output){} > > bool foo(std::string& In_Out){} > > Bei zweiter Variante ist es doch üblich eine Rückgabe zu generieren, > damit ich nach Aufruf erkenne wann sich der Wert verändert hat!? Kommt drauf an. Wenn du den String inplace veränden musst, dann Variante 2. Sonst vermutlich
bzw.
moep schrieb: > Möglichkeit 3: Den String bzw. die String-ref als Rückgabewert. Welchen Grund gibt es für die Rückgabe als Reference? Den Rückgabewert einer Funktion für die Rückgabe eines Wertes zu verwenden ist schon ziemlich verrückt!
Gast
#6413106
Technokrat schrieb: > Vielleicht könnt Ihr mir alle drei Anwendungsfälle mal beschreiben wann > Ihr die einsetzen würdet :) Ich bin wirklicher Anfänger und möchte > einfach den Unterschied und die Anwendung davon wissen Das kann man wirklich nicht sagen. Es gibt sogar Fälle wo eine Variante sehr viel Sinn machen würde, man aus guten Gründen trotzdem eine andere nimmt. Ein Beispiel, du schreibst eine Bibliothek. Für fast alle Methoden bietet sich eine Variante an. Dann schreibst du eine Methode für die eine andere Variante besser wäre. Aber, damit die Bibliothek einheitlich bleibt, bleibst du bei der ersten Variante. Anderes Beispiel, du schreibst Code auf einer Plattform (Betriebssystem, Framework, ...), wo sich eine Variante durchgesetzt hat. Dann, wenn es nicht extrem gute Gründe dagegen gibt, verwendest du in deinem Code auch diese Variante. Auch wenn die in deinem Code nicht immer optimal ist. Einheitlichkeit nimmt einem das Denken ab und vereinfacht spätere Wartung. Du kannst dich im Code auf wichtigere Dinge konzentrieren. Bei deinen Beispielen fehlen übrigens noch Varianten. Nämlich die, bei denen der Status der Methode nicht als ein bool zurückgegeben wird, sondern bei Fehlern eine Exception ausgelöst wird. P. S. schrieb: > Den Rückgabewert einer Funktion für die Rückgabe eines Wertes zu > verwenden ist schon ziemlich verrückt! Ungefähr so verrückt wie für einen Output-Paramter einen Parameter zu verwenden. 😉 P. S. schrieb: > Den Rückgabewert einer Funktion für die Rückgabe eines Wertes zu > verwenden ist schon ziemlich verrückt! Ja, ich weiß bei atoi() immer nicht, wurde eine 0 erkannt oder wurde Mumpitz übergeben. Ich verwende daher besser sscanf(). Ich hab auch mal als Returnwert eine Struct aus Wert und Fehlerstatus verwendet. Sieht aber auch nicht sonderlich praktisch aus. Peter D. schrieb: > Ich hab auch mal als Returnwert eine Struct aus Wert und Fehlerstatus > verwendet. Sieht aber auch nicht sonderlich praktisch aus. Grundsätzlich sollten imho nur Parameter als Argument übergeben werden; Ergebnisse werden returned.* Dadurch wird der Code besser wartbar und fehlerunanfälliger. Hat man mehrere Rückgabewerte, dann halt bspw. als struct oder Tuple. Für Fehler bieten sich Exceptions an; oder als Rückgabewert in einer Variant. Geht es nur um erfolgreich, oder nicht, dann als Optional. * (Es sei denn, man hat einen guten Grund der dagegen spricht. Es gitb ein paar...) Antwort schreiben |
Anzeige
|
