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

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.

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

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

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>

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

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

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.