Frage zu Exception Handling und STL-Containern in ISO-C++
-
Morgen,
ich hätte eine vermutlich einfache Frage:
Wenn ich auf einen STL-Container (genauer: einen vector) mit .at() zugreife, erhalte ich bei Zugriff über das Ende des Containers hinaus eine Exception. DAS läuft auch, wie ich es erwarte.
Wenn ich jedoch mittels operator[] auf den Container zugreife, sollte ich eine Exception erhalten oder nicht? (Ich meine: nicht!).
Das Problem:
Wenn ich VS2003 nutze, und eine catch(...) verwende, wird diese angesprungen, wenn ich mittels operator[] auf ein Element ausserhalb des vectors zugreife. Mit dem G++ geschieht dies nicht.DIE FRAGE:
Definiert der C++-Standard explizit, daß operator[] für STL-Container keine Exceptions wirft, oder ist das der Implementierung überlassen? Wie sieht das mit .at() aus?Damit will ich die Frage klären, WER jetzt standardkonform ist, und ob Microsoft(bzw. Dinkumware, wenn ich mich recht erinnere) sauber gearbeitet hat, oder das GNU STDLIB Team oder beide
Danke im Voraus.
Sid
-
zugriff hinters arrayende ist undefiniert.
da darf der rechner abschmieren, darf deine platte löschen, darf dir nen dialer installieren und nen erpresserbrief ans weisse haus schicken. alles vom standard gedeckt.
er darf unter anderem auch ne exception werfen.
-
Sid2K6 schrieb:
Das Problem:
Wenn ich VS2003 nutze, und eine catch(...) verwende, wird diese angesprungen,bei MS fängt catch(...) afair auch schutzverletzungen und divisionen durch 0, ganz ohne daß die lib was damit zu tun hat.
-
volkard schrieb:
zugriff hinters arrayende ist undefiniert.
da darf der rechner abschmieren, darf deine platte löschen, darf dir nen dialer installieren und nen erpresserbrief ans weisse haus schicken. alles vom standard gedeckt.
er darf unter anderem auch ne exception werfen.... oder rogue/nethack starten...
I *heart* undefined behaviour!
Besten Dank für die prompte Antwort. Dann hoffen wir mal, das Dinkumware das auch in der kommerziellen Version ihrer Lib zu handhaben, sonst haben wir hier ein Problem. (Was bin ich immer glücklich, wenn sowas nicht meine Schuld ist...).
Ich werde sicherlich nicht durch den Code surfen und... naja, vermutlich wirds doch mein Job...
-
volkard schrieb:
Sid2K6 schrieb:
Das Problem:
Wenn ich VS2003 nutze, und eine catch(...) verwende, wird diese angesprungen,bei MS fängt catch(...) afair auch schutzverletzungen und divisionen durch 0, ganz ohne daß die lib was damit zu tun hat.
Urgs....
-
Jetzt weiss ich auch, was dem Kollegen vermutlich passiert ist:
Entwicklung unter VS. Zugriff über Vektor schlug fehl. catch(...) wird angesprungen. Der Kollege denkt: aha, eine out_out_range exception, prüft aber den Typ nicht ab und behandelt damit eigentlich die Schutzverletzung, die durch den illegalen Zugriff ausgelöst wurde.
Kollege benutzt dieses Handling weiterhin - und DESWEGEN funktionierts mit dem G++ nicht.
Volkard: Vielen, vielen Dank. Das macht die Probleme etwas klarer...
<scherz>
Und Microsoft ist mitschuldig... wie immer... wenigstens einige Dinge ändern sich nie
</scherz>
-
Der VC++ Compiler implementiert imo Exceptions sehr seltsam.
Es wird von MS empfohlen, bei diesem Compiler die propietären Makros TRY/CATCH zu verwenden.
Mehr Infos findest du in einem MSDN Block namens "Nifty Win32 Tips" (o.ä.)
-
Hasst du mal probiert, die MS version im release mode zu fahren und zu schauen was er dann macht ?
IMHO checkt MS die speicherverletzung nur im debug modus ab, also hat er die chance auch nur im debug modus, die exception zu werfen ....Weiterhin ist mir unklar, wieso dieses undefinierte verhalten vom compiler fuer dich relevant ist ?
Im normalen code sollte der compiler nie und nimmer ne chance haben, sich undefiniert zu verhalten !!!
Kannst du 100% sicher sein, das X immer kleiner wie size ist -> kannst du den [] operator verwenden
besteht auch nur die 0.000000000001% ige chance, das X >= size ist, Hasst du at() zu verwenden und kannst die exception abfangen.
Alles andere ist mauschelei und wuerdest du von deinem Projektleiter um die ohren geworfen bekommen , und das zu recht.Ciao ....
-
Ich hab den Code nur im Review zu Gesicht bekommen.
@RHBaum Danke für den Tipp mit Debug/Release. Das bedeutet nämlich, das kein Weg um eine Korrektur dieser Probleme führt.
Wegen der Relevanz: Ich war nicht 100% sicher, ob das Verhalten undefiniert ist, deswegen ja die ursprüngliche Frage. Es lag allerdings, zugegebenerweise, ziemlich nahe. Auf gut Deutsch: Volkard hat meine Befürchtungen bestätigt.
@Headhunter: Danke für den Tipp, aber OS- oder herstellerspezifische Konstrukte kommen nicht in Frage.
-
Der VC kann verschiedene Exceptionmodele benutzen und eines davon ist eine C++ Version der Struktured-Exceptions die von der WinAPI und Windows im allgemeinen benutzt werden.
Bei einer Zugriffsverletzung wird eine Struktured-Exception geworfen.
Eine Nebenwirkung dieses VC Models ist, dass auch Struktured-Exceptions gefangen werden. Ich glaub die haben unsigned int als Type. Eine weitere Wirkung ist, dass sebst bei einer Speicherverletzung die Destuktoren aufgerufen werden.