int* pointer = new int;
delete pointer;
*pointer = 123;
cout << *pointer << endl;

Würde mich über eine Erklärung freuen.

Das Verhalten ist sehr wohl definiert. Bei dir aufm Rechner wirds immer wunderbar laufen. Beim Kunden wirds dir peinlichst um die Ohren fliegen.

Wie ist es denn definiert?

Dobi schrieb:

Das Verhalten ist sehr wohl definiert. Bei dir aufm Rechner wirds immer wunderbar laufen. Beim Kunden wirds dir peinlichst um die Ohren fliegen.

Wie ist es denn definiert?

Ich glaube du hast den Witz nicht verstanden. Das hier tatsächlich wohl definierte verhalten ist, dass mit Sicherheit Murphys Gesetz zuschlägt, wenn man undefiniertes Verhalten programmiert.

icarus2 schrieb:

Dobi schrieb:

Das Verhalten ist sehr wohl definiert. Bei dir aufm Rechner wirds immer wunderbar laufen. Beim Kunden wirds dir peinlichst um die Ohren fliegen.

Wie ist es denn definiert?

Ich glaube du hast den Witz nicht verstanden. Das hier tatsächlich wohl definierte verhalten ist, dass mit Sicherheit Murphys Gesetz zuschlägt, wenn man undefiniertes Verhalten programmiert.

Achsooo *Blush*

gibt nur den zugewiesenen Speicherbereich wieder frei, löscht aber nicht die Zeigervariabel, d.h. pointer zeigt immer noch auf die Adresse, auch wenn da jetzt nach der Freigabe sonst was drin stehen kann (undefiniert).
Deswegen ist es gut einen Zeiger nach der delete Funktion auf 0 zu setzen.

delete pointer;
pointer = 0;

if (pointer == 0)
{
    ...
}

Gruß, x3meblue

Deswegen ist es gut einen Zeiger nach der delete Funktion auf 0 zu setzen.

I disagree
Wenn du so eine Logik verwendest, ist dein Design (meistens) in den Fritten.

I disagree
Wenn du so eine Logik verwendest, ist dein Design (meistens) in den Fritten.

Sehe ich auch so. Lieber dafür sorgen, dass der Zeiger solange wie möglich gültig ist und nachher kein Zugriff mehr darauf erfolgt.

Auch delete zu verwenden ist ein Hinweis darauf, dass man vielleicht besser RAII einsetzen würde.

Deswegen ist es gut einen Zeiger nach der delete Funktion auf 0 zu setzen.

1. delete Funktion gibts nicht.
2. Es ist nicht unbedingt gut, einen Zeiger nach der delete-Funktion auf 0 zu setzen. Ausnahmen sind Zeiger, die Bestandteile von Objekten sind, und wo es in Ordnung ist, wenn die 0 sind. An allen anderen Stellen sollte der Scope so oder so kurz nach dem delete verlassen werden, der Pointer verschwinden und muss deshalb nicht "nullifiziert" werden.

[...] warum unten stehender Code funktioniert und richtig läuft.

Die offensichtliche Erklärung fehlt imho: Weil Deine Definition von "funktioniert" falsch ist. Im gegebenen Beispiel bekommst Du nur _zufällig_ das Ergebnis, was Du erwartest, obwohl das Programm inkorrekt ist.

Das wäre etwas vergleichbar damit ein kaputtes Auto einen Berg runterrollen zu lassen und dann zu argumentieren, das Auto sei ja nicht kaputt weil es fährt.

Danke für die prompten Antworten, war ja dann so wie ich es mir vorgestellt habe.

Das wäre etwas vergleichbar damit ein kaputtes Auto einen Berg runterrollen zu lassen und dann zu argumentieren, das Auto sei ja nicht kaputt weil es fährt.

Gruß, x3meblue

@Disagree: Wäre gut, wenn du auch erklären könntest warum, dann hätten alle was davon, so ist dein Beitrag sowohl überflüssig als auch nutzlos.

Gruß, x3meblue

Er hat doch erklärt, dass es auf Designfehler hindeutet. Nexus hat bessere Alternativen genannt. Wenn bei deinem Programm überhaupt die Chance besteht, dass ein ungültiger Pointer gelöscht wird, dann ist schon was falsch. Und mit dem Nullsetzen verschleppst du den Fehler auch noch, wodurch er wesentlich schwerer zu finden ist. Überhaupt sollte ein ungültiger Pointer kurz vorm Ende seiner Lebenszeit stehen (siehe auch wieder Nexus).

Nullsetzen solltest du nur, wenn dies einen besonderen Wert des Pointers bedeutet der an anderer Stelle auch geprüft wird (und zwar nicht vom delete!) und der Pointer danach überhaupt noch weiterlebt, z.B. wird das in komplexen Datenstrukturen wie Binärbäumen oft gemacht.

wieso ist es eigentlich sinnvoll (bzw nicht vom std vorgeschrieben) dass delete den zeiger nicht automatisch gleich mit auf 0 setzt?

Zweitens bekommst du kein konsistentes Verhalten hin:

int* x = new int;
int* y = x;
delete y;    // x == 0?

wieso ist es eigentlich sinnvoll (bzw nicht vom std vorgeschrieben) dass delete den zeiger nicht automatisch gleich mit auf 0 setzt?

Wurde doch schon gesagt dass das 0 setzen des Zeigers gefährlich sein kann.
Warum sollte man das also wollen?

Nie nie nie den Zeiger 0 setzen. Das fürht zu den blödsten Problemen...

Grüßla, x3meblue

Nun, an anderen Stellen hört man es umgekehrt,

Wenn du nicht auf 0 setzt und doppelt löscht stürzt dein Programm garantiert in der Testphase ab und du kannst den Bug fixen. Setzt du aber auf 0, stürtzt es garantiert nicht in der Testphase ab und du shipst den Bug zum Kunden.

Klar ist es verführerisch auf 0 zu setzen. Das bedeutet weniger entdeckte Bugs in der Testphase, das bedeutet weniger Arbeit. Aber es ist trotzdem eine schlechte Idee.

Lustigerweise höre ich diese auf 0 setzen Standpunkte nur von C++ Entwicklern. C Entwickler sind mir noch keine untergekommen die das gerne machen...

welcher bug landet denn beim kunden, wenn ich einen zeiger lösche, dann auf 0 stelle und noch mal lösche?

jenz

welcher bug landet denn beim kunden, wenn ich einen zeiger lösche, dann auf 0 stelle und noch mal lösche?

Das mag im ersten Moment nicht als Bug erscheinen, aber grundsätzlich deutet es tendenziell auf Fehler oder Probleme hin, wenn man Variablen "recycled". Es mag Stellen geben wo es Sinn macht, dies sollte aber die Ausnahme nicht die Regel sein.

Zudem ist selbst verwaltete Zeiger eine Gefahrenquelle, häufig sind ("schlanke") Smartpointer die bessere Wahl (Ich spreche hier ausschließlich von der Verwaltung, nicht von ersetzen von Zeigerübergaben etc.).

gerade b) würde man durch 0 setzen verhinden.

sowohl a) als auch b) sollte man natürlich nicht machen. kann aber bestimmt im eifer des gefechts mal passieren.
wenn, dann sollte es doch gleich in der entwicklungsphase knallen und da sehe ich b) als gefährlicher an als a)

oder?

jenz

welcher bug landet denn beim kunden, wenn ich einen zeiger lösche, dann auf 0 stelle und noch mal lösche?

Du hast einen Logikfehler in deinem Programm. Wenn du hier doppelt aufräumst ist die wahrscheinlichkeit groß, dass du vorher falsch aufgeräumt hast oder jetzt falsch aufräumst. uU wolltest du zB das erste delete ja garnicht und hast nachher noch Daten dorthin geschrieben wo früher das Objekt war und damit dem 0 Zeiger sind die nie geschrieben worden.

Fakt ist: doppeltes Aufräumen ist ein Logikfehler.
Weiterer Fakt ist: nur in altem C++ Code wird das versucht wegzudiskutieren. In anderen Sprachen (auch C) wird sowas garnicht erst diskutiert und nie benutzt.

Es geht dabei nicht darum dass es schlecht ist Variablen zu recyclen - denn Zeiger auf 0 setzen macht durchaus Sinn - nur automatisch mit jedem delete auf 0 setzen ist das Problem.

Die Denkweise: wenn es nicht abstürtzt ist es korrekt - ist hier das Problem.
Dabei sind Abstürze gut. Wir wollen Abstürze. Sie helfen Fehler zu finden.

allerdings bin ich mir nicht ganz so sicher, dass es _immer_ ein logikfehler ist, wenn man doppelt löscht.
aber man kann es auch jedenfall immer so lösen, dass man nicht doppelt löscht.

jenz