Wieviel Kontrolle ist empfohlen

Bock

Hoi,

Ich bin momentan dabei ein größeres Project zu schreiben, aber ich bin mir noch nicht sicher, wieviel Kontrolle nötig oder empfohlen ist.

Zum Beispiel, ich habe eine Array Klasse geschrieben. Diese hat eine Überladung für den [] operator.
Wenn man nun einen größeren Index angibt als es Elemente gibt, sollte ich dann einfach das letzte Element zurückgeben, oder eine Exception werfen?

array<char> ar(10); //einen Array von 10 char Elementen

cout << ar[10]; // ich greife auf das 11 Element zu, welches es gar nicht gibt
                // soll ich jetzt Element 10 zurückgeben oder eine Exception 
                //werfen?

Das ist nur ein Beispiel wo ich mir nicht sicher bin.

mfg

Wenn man nun einen größeren Index angibt als es Elemente gibt, sollte ich dann einfach das letzte Element zurückgeben,

*lol*, auf gar keinen Fall.

volkard

Bock schrieb:

Zum Beispiel, ich habe eine Array Klasse geschrieben. Diese hat eine Überladung für den [] operator.
Wenn man nun einen größeren Index angibt als es Elemente gibt, sollte ich dann einfach das letzte Element zurückgeben, oder eine Exception werfen?

weder noch!

mach assert rein und gut ists. ein zu großer index ist immer ein programmierfehler. du musst dafür sorgen, daß so ein programmierfehler dir sofort auffält und du den code reparierst.

Apollon

Ich plaediere fuer Exception.

rüdiger

Apollon schrieb:

Ich plaediere fuer Exception.

Exceptions halte ich hier nicht für sinnvoll, da es sich ja in der Regel um Programmierfehler handelt, wenn man einen zu großen Array Index hat. Eine Exception ist für mich eher etwas, was im normalen Programmablauf passieren kann.

Wenn schon eine Exception-Variante, dann würde ich dafür nicht den operator[] benutzen, sondern eine Methode at(), wie es auch der STL-vector macht.

volkard

Apollon schrieb:

Ich plaediere fuer Exception.

zu teuer.

wenn man's ernsthaft macht, baut man sich ein eigenes ASSERT-makro, das einen in den debugger wirft, falls der debugger an ist und dann ne exception wirft, die __FILE__ und __LINE__ enthält, aber alles nur, wenn nicht NDEBUG definiert ist.

Bock

Moin,

Auf die Idee mit dem letzten Element zurückgeben bin ich nur gekommen, weil es in der Standart Bibliothek ähnlich behandelt wird.
Wenn man zum Beispiel einen SubString haben will:

string s1;
s1="Hallo";

string s2;
s2=s1.substr(0,1000); // der Index ist viel zu groß deshalb wird alles von 0 bis Ende zurückgegeben;

Aber zu den Asserts. Wenn ich zum Beispiel einen Array von Vectoren mache und dann ein Modell rendern will, hole ich mir ja alle Informationen aus der Mesh-Datei.
Da kann es des öfteren mal passieren, dass ein Index überschritten wird.
Das könnte aber noch in der Final Version passieren, also musss ich ja irgendwie reagieren können.

Ich denke ich werde mal eine Exception einbauen.

Zeus

Exception sind nicht dazu da, um Plausibilitätsprüfungen durchzuführen.
In deinem Beispeil steht .substr wenn die das Argument höher ist als der Stringlänge dann nehment die Funktion die maximale Länge des Strings.

Richtige Verwendung von Exception ist zum Beispiel:
Wenn du eine Clientprogramm hast und diese auf Daten vom Server wartet, aber sie nicht kommen, dann kannst du mit eine Exception angemessen darauf reagieren, sei es ausweichen auf ein anderen Server, Messagebox "Server nicht erreichbar" oder sonstwas.

Aber Plausibilitätsprüfungen gehört zu deine Programmieraufgabe.

rüdiger

Bock schrieb:

Ich denke ich werde mal eine Exception einbauen.

Dann implementier lieber eine Methode ala .at() dafür, so wie es die STL auch macht.

Im Grunde würde ich, wenn es für dein Programm "normal" ist, über die Array-Größe hinaus zu lesen, keine Exception benutzen. Da Exceptions ja für Ausnahmen und nicht für normales Programmverhalten gedacht sind.

Im Grunde würde ich, wenn es für dein Programm "normal" ist, über die Array-Größe hinaus zu lesen, keine Exception benutzen. Da Exceptions ja für Ausnahmen und nicht für normales Programmverhalten gedacht sind.

Eben, denn im Release-Mode können ja gar keine Fehler auftreten, da kann man sie getrost ignorieren ...

Bock

Rüdiger meinte ich sollte lieber eine Methode wie at() einbauen.
Aber diese Methode schmeißt doch eben eine Exeption.

http://www.cppreference.com/cppstring/at.html

Instead of attempting to read garbage values
 from memory, the at() function will realize 
that it is about to overrun the vector and will throw an exception.

rüdiger

Bock schrieb:

Rüdiger meinte ich sollte lieber eine Methode wie at() einbauen.
Aber diese Methode schmeißt doch eben eine Exeption.

http://www.cppreference.com/cppstring/at.html
Instead of attempting to read garbage values
 from memory, the at() function will realize 
that it is about to overrun the vector and will throw an exception.

Da hast du mich missverstanden. Ich meinte das eher so, dass du bevor du operator[] mit einer Exception implementierst, lieber eine Funktion at() mit einer Exception implementieren solltest.

rüdiger schrieb:

Da hast du mich missverstanden. Ich meinte das eher so, dass du bevor du operator[] mit einer Exception implementierst, lieber eine Funktion at() mit einer Exception implementieren solltest.

Was genau versprichst du dir dadurch? Was hast du von einer Zugriffsfunktion, die Fehler "verschluckt" indem sie keine Exception wirft? Letztendlich musst du dann einfach selbst überprüfen, ob der Index gültig ist und das ist auf Dauer gesehen reiner "boiling-plate" code, der mit Exceptions hätte vermieden werden können.

rüdiger

exceptions` schrieb:

rüdiger schrieb:

Da hast du mich missverstanden. Ich meinte das eher so, dass du bevor du operator[] mit einer Exception implementierst, lieber eine Funktion at() mit einer Exception implementieren solltest.

Was genau versprichst du dir dadurch? Was hast du von einer Zugriffsfunktion, die Fehler "verschluckt" indem sie keine Exception wirft? Letztendlich musst du dann einfach selbst überprüfen, ob der Index gültig ist und das ist auf Dauer gesehen reiner "boiling-plate" code, der mit Exceptions hätte vermieden werden können.

Ich würde in den operator[] ein assert einbauen. So kann man im Debug-Modus prüfen, hat im Release aber keinen Overhead. Wer mehr Sicherheit will kann dann at-nehmen.

Bock

Achso...

Vielen Dank für eure Antworten.
Ich denke ich werde es wie Rüdiger meinte machen, nur halt genau umgekehrt.
Beim

operator[]

werde ich eine überprüfung einbauen und eine extra Methode die einfach alles blind macht(im Debug halt noch ein assert).
So überlegt man sich 2 mal ob man wirklich kein Risiko eingeht.

mfg Bock

volkard

also statt beim speichern aus dem editor auf plausibilität zu prüfen, bzw im makefile, es erst bei laden zu machen, halte ich ja schon für befremdlich.
aber es sogar vom laden zu verschieben auf immer, da muss ich mir erstmal uml-diagramme dazu erstellen, damit ich das genau nachvollziehen kann und eventuell einen fachmann fragen, der durch java 100% objektorientierung kann.

finix

exceptions` schrieb:

rüdiger schrieb:

Da hast du mich missverstanden. Ich meinte das eher so, dass du bevor du operator[] mit einer Exception implementierst, lieber eine Funktion at() mit einer Exception implementieren solltest.

Was genau versprichst du dir dadurch? Was hast du von einer Zugriffsfunktion, die Fehler "verschluckt" indem sie keine Exception wirft? Letztendlich musst du dann einfach selbst überprüfen, ob der Index gültig ist und das ist auf Dauer gesehen reiner "boiling-plate" code, der mit Exceptions hätte vermieden werden können.

Dir scheint nicht klar zu sein dass du oftmals eben nicht prüfen musst ob der Index gültig ist, da du von vorneherein schon weisst dass er nicht ungültig sein kann.

finix schrieb:

Dir scheint nicht klar zu sein dass du oftmals eben nicht prüfen musst ob der Index gültig ist, da du von vorneherein schon weisst dass er nicht ungültig sein kann.

Selbst in Situationen bei einer simplen Schleife über den gesamten Vektor (std::vector) kann man dank Multi-Threading nicht davon ausgehen, dass man die Index Grenzen derartig 100% weiß. Außerdem tut ihr ja gerade so als würde eine lächerliche Überprüfung mit entsprechender Exception hinterher wirklich Auswirkungen auf die Performance ausmachen ..

Walli

exceptions` schrieb:

finix schrieb:

Dir scheint nicht klar zu sein dass du oftmals eben nicht prüfen musst ob der Index gültig ist, da du von vorneherein schon weisst dass er nicht ungültig sein kann.

Selbst in Situationen bei einer simplen Schleife über den gesamten Vektor (std::vector) kann man dank Multi-Threading nicht davon ausgehen, dass man die Index Grenzen derartig 100% weiß.

Soll die Datenstruktur jetzt plötzlich Rücksicht darauf nehmen, wenn jemand beim Thema Multithreading nicht aufgepasst hat?

Soll die Datenstruktur jetzt plötzlich Rücksicht darauf nehmen, wenn jemand beim Thema Multithreading nicht aufgepasst hat?

Eine thread-sichere Datenstruktur? Wie komme ich denn nur auf eine derartig absurde Idee. Da muss ich wohl eingeraucht gewesen sein ..