C++: Variablenübergabe Funktion: In/Out oder In Out Seperat?

[Technokrat (Gast)]

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!?

[moep (Gast)]

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?

[Oliver S. (oliverso)]

Radio Eriwan sagt: Es kommt darauf an...

Nämlich darauf, was das ganze überhaupt soll.

Oliver

[Technokrat (Gast)]

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

[mh (Gast)]

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

std::string foo(std::string const& Input);

bzw.

std::string foo(std::string_view Input);

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?

[P. S. (namnyef)]

Den Rückgabewert einer Funktion für die Rückgabe eines Wertes zu 
verwenden ist schon ziemlich verrückt!

[Sandor (Gast)]

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.

[Rolf M. (rmagnus)]

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. 😉

[Peter D. (peda)]

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.

[Mikro 7. (mikro77)]

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...)