"Leere" Referenz zurückgeben

[ChockoCookie]

Der sinn von Referenzen ist, das sie eben nicht leer sein können. Typischerweise würde man hier eine exception werfen.

[otze]

@choko ist in einem container das nicht vorhanden sein eines gesuchten schlüssels eine ausnahme?

@topic der einfachste weg währe, garkeine referenzen zurückzugeben, sodnern zeiger, dass macht die stl in der map auch so.

der von miller_m vorgeschlagene prototyp kann nicht funktionieren, da referenzen keine objekte sind, und somit nur einmal bei ihrem erstellen zuweisbar sind, und jede nachfolgende aktion sich nichtmehr auf die referenz, sondern auf das objekt hinter der referenz auswirkt.

bool get_ref(const char *pKey, CMyClass &ref) {
    ref=irgendeinobjekt;
}

das würde also das objekt hinter ref ändern, und nicht ref selber, was nicht sinn der sache ist.

[ChockoCookie]

Kommt drauf an, man könnte ja eine isKeyAvailable() funktion bereitstellen. Aber das ist performance - technisch schwachsinn. In Vielen Fällen, weist ein Nichtvorhandensein eines gesuchten Keys auf einen Fehler hin. Entweder im Programm oder eine Fehlerhafte Eingabe des Benutzers.
Ich denke jedenfalls exceptions sind ein geeignetes Sprachmittel für diesen Fall und auch eleganter als einen übergebenen Pointer zu befüllen.

[otze]

eine fehlerhafte eingabe des benutzers würdest du also mit ner exception quitieren? Oo

btw: was meinst du, was find() in der map ist? es ist eigentlich genau dein isKeyAvailable, damit man nicht ausversehen irgendwelche keys überschreibt. ansonsten kann man ja ganz einfach den op[] verwenden(sofern er implementiert ist).

[HaJo.]

otze schrieb:

eine fehlerhafte eingabe des benutzers würdest du also mit ner exception quitieren? Oo

btw: was meinst du, was find() in der map ist? es ist eigentlich genau dein isKeyAvailable, damit man nicht ausversehen irgendwelche keys überschreibt. ansonsten kann man ja ganz einfach den op[] verwenden(sofern er implementiert ist).

Ja, der Index Operator ist vorhanden und zwar als

CMyClass & operator [] (int index)

und

CMyClass & operator [] (const char *pKey)

Hier ist ebenfalls das Problem der "leeren" Referenz.

Einen Pointer wollte ich eigentlich nicht zurückgeben und eine Exception ist imho zu viel des Guten.

[otze]

beim op[] wird ein default objekt erstellt(aufjedenfall in der map),musst schaun, was du machst^^

[hä??????]

Einen Pointer wollte ich eigentlich nicht zurückgeben

Und warum nicht?

[ChockoCookie]

otze schrieb:

eine fehlerhafte eingabe des benutzers würdest du also mit ner exception quitieren

... mit der man rechnet und die man fängt. Tatsache ist jedenfalls, das das Nichtfinden eines Key mit dem Fehlschlagen der Funktion gleichsetzen kann, da man es nicht erwartet. Man erwartet, das der Key, den man sucht gefunden wird ausgenommen es gibt ihn nicht. Aber ob man jetzt schreibt

if (key == 0){}

oder 

catch (KeyNotFound &ex){}

Ist wohl letztendlich geschmackssache. Und exceptions sind nun mal das Mittel zur Fehlerbehandlung in C++. Oder gibt es einen gewichtigen Grund, das man exceptions in diesem Fall nicht verwenden sollte?

[edit]
Was natürlich auch geht, ist eine Klasse für den Rückgabewert zu definieren, die auch anzeigen kann, wenn etwas nicht gefunden wurde. zB wie iteratoren. Wäre wohl imho die beste Lösung. (Ja ich weis otze, das hast du mit "map gibt Pointer zurück" gemeint)
[/edit]

[otze]

... mit der man rechnet und die man fängt. Tatsache ist jedenfalls, das das Nichtfinden eines Key mit dem Fehlschlagen der Funktion gleichsetzen kann, da man es nicht erwartet.

bei einem assoziativen container erwarte ich aber die situation, dass der key nicht gefunden wird. es ist keine ausnahme, es ist ein normales verhalten der map.

if(!key){
   ...
   key=irgendwas
}
use(key)

und das mit extrem langsamen exceptions?

der hauptgrund aber, wieso man keine exception werfen sollte, ist, dass es ein logischer fehler ist, der mit einem assert beantwortet wird.

[ChockoCookie]

otze schrieb:

bei einem assoziativen container erwarte ich aber die situation, dass der key nicht gefunden wird.

Situation 1: Man holt sich einen Key von dem man glaubt zu wissen das es ihn gibt.
Situation 2: Man will testen ob es einen Key gibt --> isAvailable

Vielleicht gibts auch noch was anderes. Kommt wohl auf die Anwendung an.

Aber wie langsam sind denn exceptions nun?

Ansonsten: siehe Edit zu meinem Vorposting

[otze]

Aber wie langsam sind denn exceptions nun?

implementationsspezifisch soweit ich weis. aber aufjedenfall langsamer als ein if

[Jester]

Eine dritte Möglichkeit, die sich manchmal anbietet ist ein null-Objekt zurückzuliefern. Also ein Objekt, das den Zustand nix gefunden repräsentiert. Und das tut es, indem es alle Methoden implementiert, die das normale Objekt auch gehabt hätte, nur tut es einfach nichts.

Das macht natürlich nicht immer Sinn. Aber manchmal kann man damit seinen Code von solchen Anfragen befreien.

MfG Jester

[Irgendwer]

otze schrieb:

... mit der man rechnet und die man fängt. Tatsache ist jedenfalls, das das Nichtfinden eines Key mit dem Fehlschlagen der Funktion gleichsetzen kann, da man es nicht erwartet.

bei einem assoziativen container erwarte ich aber die situation, dass der key nicht gefunden wird. es ist keine ausnahme, es ist ein normales verhalten der map.

if(!key){
   ...
   key=irgendwas
}
use(key)

und das mit extrem langsamen exceptions?

Wenn es ein Eingabefehler des Users ist spielt Geschindigkeit doch keine Rolle mehr. Man muss eh auf die Korrektur durch den User warten.

otze schrieb:

der hauptgrund aber, wieso man keine exception werfen sollte, ist, dass es ein logischer fehler ist, der mit einem assert beantwortet wird.

Ein Eingabefehler des Users würdest du also mit assert entgegen treten? Na wenn das mal gut geht...

otze schrieb:

eine fehlerhafte eingabe des benutzers würdest du also mit ner exception quitieren? Oo

Ich seh nicht wieso ich es nicht so tun soll.

[Jester]

Exceptions sind für Ausnahmen. Und damit sind wirkliche Ausnahmen gemeint. Also irgendetwas, das das Programm vom normalen Ablauf wegzwingt. Wenn man aber von der Eingabe eines Nutzers abhängt, dann muß man auch einplanen, daß derjenige was nicht so sinnvolles eingibt. Das ist dann also ein mehr oder weniger normaler Fall, der deshalb auch nicht mit Exceptions behandelt werden sollte.

Exceptions eher für Sachen, die normalerweise nicht schief gehen sollten.