T* foo = new T();
T* bar = foo ;
delete foo ;

bar->machWas() ; // undefined oder implementation defined

ist das verwenden eines dangling pointers undefiniert, oder vom Compiler hHersteller abhängig?

und gab es hier änderungen? Ich fand diese
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1438
jedoch hier,
http://cs.nyu.edu/courses/summer11/G22.2110-001/documents/c++2003std.pdf
finde ich nichts dazu. 3.7.4 ist recht kurz im original standard.

oder schau ich sowieso bei der falschen Stelle nach?

Vielleicht verstehe ich auch deine Frage nicht ganz richtig, denn die zitierte Passage hat nicht direkt etwas damit zu tun, wie ich deine Frage verstanden habe.

T* foo = new T();
delete foo;
T* dieseKopieIstUB = foo;

Hier wird also foo nochmal verwendet, nachdem foo deleted wurde. Der Artikel stellt die Frage, ob es nötig ist, dass obige Kopie UB ist. Es geht nicht darum, die Kopie auch zu dereferenzieren, was klar UB ist.

es wird ein Pointer verwendet der zu einem Objekt zeigt welches gelöscht wurde

Verwendung eines invalid pointer value

http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
6.3.2.3 Pointers Punkt 20 meint undefiniert.

Das meine ich auch.

Es gibt Kollegen die meinen es ist garantiert das es sofort crashed.
(crash is ok, fix daher später)

Ich will ich den Bug raufpriorisieren weil Crash => Restart eben nicht garantierte, sondern nur sehr wahrscheinlich ist, meiner bescheidenen Meinung nach.

Ich brauch aber ein Dokument auf welches ich verweisen kann, am besten eben C++ Standard, (Version 03), damit das ohne weitere Diskussion durchgeht.

Ich brauch aber ein Dokument auf welches ich verweisen kann, am besten eben C++ Standard, (Version 03), damit das ohne weitere Diskussion durchgeht.

Das Dokument hast du ja schon. Es ist undefined behavior. Es kann passieren das da was crasht, du hast aber auch ne gute Chance das es einfach weiterläuft und irgendwo anders dann ggf Daten zerschossen werden wenn du pech hast.

Es gibt Kollegen die meinen es ist garantiert das es sofort crashed.

So eine Art von Verhalten gibt es im Standard nicht, weil es völlig unklar wäre, was als Crash gilt, und welche Art von Crash überhaupt auf allen Plattformen implementierbar ist. Deine Platform könnte einen Crash festlegen. Auf einem gewöhnlichen System generiert bspw. die MMU einen trap, welcher dann über dein OS als Segfault gemeldet wird. Auf einem System ohne entsprechende Hardware wird es vielleicht anders ausgehen. Dieses Systemabhängige Ausnahmeverhalten ist als "undefiniertes Verhalten" im Standard zu finden.

Ich brauch aber ein Dokument auf welches ich verweisen kann, am besten eben C++ Standard, (Version 03), damit das ohne weitere Diskussion durchgeht.

Es macht wenig Sinn sich auf C++03 zu beschränken, wenn die Chance besteht, defekte Teile zu zitieren. Wenn die Teile nicht defekt sind, hätte man gleich C++14 zitieren können (welches im Übrigen auch eher auf das Verhalten aktueller Implementierungen zutrifft, und ich hoffe doch stark, dass ihr nicht mit VS2005 arbeitet).

Das Dokument hast du ja schon. Es ist undefined behavior. Es kann passieren das da was crasht, du hast aber auch ne gute Chance das es einfach weiterläuft und irgendwo anders dann ggf Daten zerschossen werden wenn du pech hast.

ja, hab sogar was besseres gefunden, nutzte nur leider nix.

Arcoth schrieb:

So eine Art von Verhalten gibt es im Standard nicht, weil es völlig unklar wäre, was als Crash gilt, und welche Art von Crash überhaupt auf allen Plattformen implementierbar ist. Deine Platform könnte einen Crash festlegen. Auf einem gewöhnlichen System generiert bspw. die MMU einen trap, welcher dann über dein OS als Segfault gemeldet wird. Auf einem System ohne entsprechende Hardware wird es vielleicht anders ausgehen. Dieses Systemabhängige Ausnahmeverhalten ist als "undefiniertes Verhalten" im Standard zu finden.

ja eben, das denke ich auch und ich bin der Meinung wenn man Qualität liefern sollte dann macht man einfach den existierenden fix noch ins bevorstehende Release weil das geht schneller als ewig drüber zu diskutieren. (cherrypick 5 Minuten, Testen 0,5 Tage 1 Person, Diskussion= mehrere Leute sind den halben Tag, eventuell länger, abgelegt)

Arcoth schrieb:

Es macht wenig Sinn sich auf C++03 zu beschränken, wenn die Chance besteht, defekte Teile zu zitieren. Wenn die Teile nicht defekt sind, hätte man gleich C++14 zitieren können (welches im Übrigen auch eher auf das Verhalten aktueller Implementierungen zutrifft, und ich hoffe doch stark, dass ihr nicht mit VS2005 arbeitet).

da hast du recht, nur muss es jetzaein C++03 document sein weil sonst sagt mir der Code Author das ich von was ganz anderem spreche.
gcc, nicht die aktuellste weil mehrerer Plattformen, x86, unterschiedliche arm, die embedded Welt bewegt sich langsam.

hier gibt es etwas dazu,
http://cs.nyu.edu/courses/summer11/G22.2110-001/documents/c++2003std.pdf

3.7.3.2 Punkt 4 das selbe wie im C Standard, nur mit einer Fussnote das Hersteller einen vielleicht einen Crash implementieren ... das reichte, wir fixen später,
egal, ich hab es dokumentiert, es ist nur ein Job, irgendwann lande ich in einem Umfeld die Qualität ähnlich ernst nimmt ... bis dahin hoffe ich dass ich mich nicht zu sehr anpasse, und versuche zu lernen warum es besser sein kann wenn viele Leute einen Halben Tag lang reden und nix tun, als 1 Person einen halben Tag lang arbeitet und etwas repariert