Grundsätzlich: Strings als Übergebeparameter

Shade Of Mine

variante 1.

welchen sinn sollte variante 2 haben?

pumuckl

Roger Wilco schrieb:

@all: Und welche Variante bevorzugt ihr für Strings als Rückgabewert?

Kommt drauf an, das ist eine Frage der Fehlerbehandlung. Wenn es "normal" ist, dass kein Filename zurückgegeben werden kann, ist die zweite Version durchaus legitim (oder die erste mit leerem String, um anzuzeigen dass da nix kommt), andernfalls wenn eigentlich immer ein Filename zurückgegeben werden kann, die erste Version und im Notfall eine Exception werfen.

Roger Wilco

Shade Of Mine schrieb:

welchen sinn sollte variante 2 haben?

Ich dachte sie wäre (minimal) schneller, da keine Kopie gemacht wird. (Zusätzlich hat man gleich eine kompakte SUCCESS/FAILURE-Behandlungsmöglichkeit.)

Shade Of Mine

Roger Wilco schrieb:

Ich dachte sie wäre (minimal) schneller, da keine Kopie gemacht wird. (Zusätzlich hat man gleich eine kompakte SUCCESS/FAILURE-Behandlungsmöglichkeit.)

Unter Laborbedienungen wäre die Variante mit direktem Return vermutlich schneller. In der freien Wildbahn hängt es von zuvielen Faktoren ab...

SUCCESS/FAILURE wird mittels exceptions gelöst. Return Werte sind sowas von letztem jahrhundert...

Ich mache immer die erste Variante. In vielen Fällen optimiert der Compiler das Kopieren nämlich weg! Gibts glaube ich sogar einen Begriff dafür, wenn ein Rückgabewert wegoptimiert werden kann.

Bei sowas sollte man nicht versuchen schlauer zu sein als Compiler, wenn es auf Codeverständnis geht.

Weiterhin würde ich bei einem unerwarteten Fehler eine Exception werfen.

Roger Wilco

Vielen Dank soweit für Eure Meinungen und Ratschläge!

Zum Thema Exceptions: Davor habe ich mich bisher immer gedrückt.

Das Prinzip ist mir klar, aber wie werden die in einem Projekt sinnvoll (einheitlich, plausibel etc.) eingesetzt. Mir fehlen da einfach Ansätze für ein Prinzip, eine einheitliches und sinnvolles Verfahren.

Das fängt ja an beim Design von Exceptions, deren Klassifizierung etc...

Daher noch die alte Returnwert-Prüfung zur Fehlerbehandlung.

Wenn es da hilfreiche Links oder Literatur gibt, wäre ich sehr dankbar.

SUCCESS/FAILURE wird mittels exceptions gelöst. Return Werte sind sowas von letztem jahrhundert...

Hmm, Exceptions sind fuer Ausnahmen da. Bei z.B. falschen Nutzereingaben fuer Dateien sollte keine Exception geworfen werden. Auch sollte bei Ressourcemanagement auf Exceptions verzichtet werden. Java/C# gehen da andere Wege als C++. Returnwerte sind also sowas von nicht letztes Jahrhundert.

asc

Roger Wilco schrieb:

Zum Thema Exceptions: Davor habe ich mich bisher immer gedrückt.

...

Das fängt ja an beim Design von Exceptions, deren Klassifizierung etc...

Daher noch die alte Returnwert-Prüfung zur Fehlerbehandlung.

Naja, Returnwerte musst du auch Klassifizieren (Ohne zu wissen wofür ein Rückgabewert steht, kann man diesen auch nicht verwerten), und vor allem lassen sich Rückgabewerte sehr einfach "vergessen".

cu André

Shade Of Mine

knivil schrieb:

Hmm, Exceptions sind fuer Ausnahmen da. Bei z.B. falschen Nutzereingaben fuer Dateien sollte keine Exception geworfen werden. Auch sollte bei Ressourcemanagement auf Exceptions verzichtet werden. Java/C# gehen da andere Wege als C++. Returnwerte sind also sowas von nicht letztes Jahrhundert.

Ich sagte im Falle von Failure/Success verwendet man exception. wenn nix fehlschlägt, fliegt auch keine exception...

und gerade bei resourcen management verwendet man exceptions - stichwort: RAII/RRID

@Roger Wilco:
siehe http://magazin.c-plusplus.net/artikel/Modernes Exception-Handling Teil 1 - Die Grundlagen

volkard

knivil schrieb:

Hmm, Exceptions sind fuer Ausnahmen da. Bei z.B. falschen Nutzereingaben fuer Dateien sollte keine Exception geworfen werden.

richtig.

knivil schrieb:

Returnwerte sind also sowas von nicht letztes Jahrhundert.

falsch.

denn GetFilename sollte nicht aufgerufen werden, wenns nur daran lag, daß der benutzer dumme sachen eingegeben hat. da wäre eine exception schlecht. und der returnwert unnötig. assert wäre gut.

aber GetFilename könnte auch fehlschlagen wegen eines lesefehlers auf der platte. sowas unerwartetes fordert ne exception. willst du alle unerwarteten sachen mit fehlerrückgaben und if hochreichen, bläht sich dein code aufs doppelte auf und wird auch nicht mehr fein lesbar sein. geschweige denn wartbar.

asc

knivil schrieb:

Auch sollte bei Ressourcemanagement auf Exceptions verzichtet werden.

Weswegen? RAII arbeitet ja gerade auf Basis von Scopes und Exceptions (Bzw. erhält man dank RAII meist Exceptionsicherheit).

knivil schrieb:

SUCCESS/FAILURE wird mittels exceptions gelöst. Return Werte sind sowas von letztem jahrhundert...

Hmm, Exceptions sind fuer Ausnahmen da. Bei z.B. falschen Nutzereingaben fuer Dateien sollte keine Exception geworfen werden.

Kommt darauf an. Wenn man die fehlerhaften Nutzereingaben direkt an Ort und Stelle wieder beheben kann (z.B. um nochmalige Eingabe bitten) sind Exceptions fehl am Platz. Wenn aber die Fehlangaben an dieser Stelle nicht korrigiert werden können kann eine Exception durchaus Sinn machen.

Grob gesagt würde ich Exceptions im Fehlerfall, Rückgabewerte im Statusfall anwenden (Und bei Gettern beispielsweise ist für mich der Rückgabewert immer das, was ich von der Getter haben will. Wenn ich keine Daten erhalten kann, wiederspricht dies einer Funktion einer Getter-Methode und ich sehe dies als Fehler - als Exception - an).

cu André

Nexus

pumuckl schrieb:

Das ist eine Frage des Schnittstellendesigns. Tendenziell würde ich die Schnittstelle eher schmal halten, sprich nur std::wstring. Es ist dann Sache des Aufrufers bei eventuell auftretenden wchar_t-Pointern die nötigen Überprüfungen vorzunehmen.

Um das genau zu sagen, müsste man die Aufgaben der Klasse kennen. Wenn innerhalb ein wchar_t* verwendet wird und dessen Wert optional ist (also entweder ein gültiger WString oder Null), würde ich an der Schnittstelle auch eine Funktion mit wchar_t* -Parameter hinzufügen. Weil eben auch Null möglich ist.

Zum Thema Exceptions ist es eigentlich ähnlich; wenn man erwartet, dass eine Funktion einen String zurückliefert, dann sollte im Fehlerfall eine Exception geworfen werden. Wenn es aber darum geht, irgendeinen Status abzufragen, der entweder nicht verwendet wird (Null) oder einen WString repräsentiert (gültiger wchar_t* ), ist auch ein Rückgabewert angebracht.

Ich kann wunderbar RAI machen ohne auch nur an Exceptions zu denken. RAI hat in erster Linie nichts mit Exceptions zu tun.

Shade Of Mine

knivil schrieb:

Ich kann wunderbar RAI machen ohne auch nur an Exceptions zu denken. RAI hat in erster Linie nichts mit Exceptions zu tun.

RAII mit doppel I!

Natuerlich geht es auch ohne Exception, aber dann hat man wieder ein paar der Probleme die man ohne RAII auch hat. Und das will man ja eigentlich nicht

Lies dir mal meinen Artikel ueber Exceptions durch.
Am Ende gehe ich auch kurz auf alternativen ein - aber Exceptions und RAII spielen halt wundertoll zusammen - so dass man eigentlich fahrlaessig handelt es nicht auszunutzen...