Hab dieses kleine Codeconstruct "erfunden" als ich einige Crashes im Debugger nachstellen wollte.
Das lustige:
Unter Visual Studio kompiliert bleibt das Programm stehen und die Konsole hängt sich auf.
Mit dem gcc kompiliert funktioniert es.
Was sagt denn hier der Standard dazu? Ist das das, was man undefiniertes Verhalten nennt?
Die Ausgabe findet aber noch statt.
rya.

void foo::crashMe(bar* f)
{
	f->DoSomething(this);
	cout << "Hello still here" << endl;
}

void bar::DoSomething(foo* f)
{
	delete f; f= NULL;
}

int main()
{
	foo* f = new foo;
	bar* b = new bar;
	f->crashMe(b);
	delete f;
}

Hab dieses kleine Codeconstruct "erfunden" als ich einige Crashes im Debugger nachstellen wollte.
Das lustige:
Unter Visual Studio kompiliert bleibt das Programm stehen und die Konsole hängt sich auf.
Mit dem gcc kompiliert funktioniert es.
Was sagt denn hier der Standard dazu? Ist das das, was man undefiniertes Verhalten nennt?
Die Ausgabe findet aber noch statt.
rya.

Zweifaches delete -> undefiniertes Verhalten

Aber warum funktioniert es trotzdem? Der Deconstructor wird vor der Ausgabe ausgeführt.
Weil es in dem Moment schon auf dem Stack liegt? Ist dieses Verhalten garantiert?
rya.

Däng sollte delete b; heissen -.-. Ok gut :D. Meine Blödheit.

Aber warum funktioniert es trotzdem? Der Deconstructor wird vor der Ausgabe ausgeführt.
Weil es in dem Moment schon auf dem Stack liegt? Ist dieses Verhalten garantiert?
rya.

Außerdem kannst mir den Zweck von

f= NULL;

noch erklären

Däng sollte delete b; heissen -.-. Ok gut :D. Meine Blödheit.

Aber warum funktioniert es trotzdem? Der Deconstructor wird vor der Ausgabe ausgeführt.
Weil es in dem Moment schon auf dem Stack liegt? Ist dieses Verhalten garantiert?
rya.

Ich vermute mal, weil intern der Destruktor aufgerufen wird (also nicht delete) und dann per free der Speicherbereich freigegeben wird.

Nur eine Vermutung!
Und sicherlich ist zweite Aufruf des Destruktors nicht garantiert

Aber warum funktioniert es trotzdem? Der Deconstructor wird vor der Ausgabe ausgeführt.
Weil es in dem Moment schon auf dem Stack liegt? Ist dieses Verhalten garantiert?

Nein, wie schon gesagt undefiniertes Verhalten. Abgesehen davon heisst es "Destruktor" und nicht "Deconstructor".

Außerdem kannst mir den Zweck von

f= NULL;

noch erklären

delete f; f=NULL;

bedeutet

delete f; assert("Bin Anfänger");

CSpille schrieb:

Außerdem kannst mir den Zweck von

f= NULL;

noch erklären

delete f; f=NULL;

bedeutet

delete f; assert("Bin Anfänger");

wxWidgets, Datei defs.h:

// delete pointer if it is not NULL and NULL it afterwards
    template <typename T>
    inline void wxDELETE(T*& ptr)
    {
        typedef char TypeIsCompleteCheck[sizeof(T)];

        if ( ptr != NULL )
        {
            delete ptr;
            ptr = NULL;
        }
    }

Warum mach ich das und auch andere wie man sieht? Damit der nächste Test auf NULL für den Zeiger auch funktioniert... wird in einigen Tutorials aufgeführt und habs auch schon in Büchern gesehen.
Ausserdem schon selber Crashes gehabt, weil ein Test eines Zeigers auf NULL ohne diesen Zusatz nicht funktioniert hat.
rya.

Warum mach ich das und auch andere wie man sieht? Damit der nächste Test auf NULL für den Zeiger auch funktioniert... wird in einigen Tutorials aufgeführt und habs auch schon in Büchern gesehen

Achte mal ganz genau auf den Parametertypen...

... macht auch schon nicht viel Sinn die Abfrage.

wxWidgets, Datei defs.h:

// delete pointer if it is not NULL and NULL it afterwards
    template <typename T>
    inline void wxDELETE(T*& ptr)
    {
        typedef char TypeIsCompleteCheck[sizeof(T)];

        if ( ptr != NULL )
        {
            delete ptr;
            ptr = NULL;
        }
    }

Abgesehen davon, dass das eine Referenz ist und bei dir nicht, zeigt schon das if(ptr != NULL) , dass hier nicht unbedingt ein C++-Kenner gewerkelt hat

Warum mach ich das und auch andere wie man sieht?

Schlechte Bücher und Tutorials. Übergib sie der reinigenden Kraft des Feuers.

Warum mach ich das und auch andere wie man sieht?

Als kleines Beispiel für die Anmerkungen der vorherigen Beiträge:

#include <iostream>

class A {
public:
};

void delPtrRef(A*& a){
        delete a;
        a = 0;
        std::cout << a << std::endl;
}

void delPtr(A* a){
        delete a;
        a = 0;
        std::cout << a << std::endl;
}

int main()
{
        A* a = new A();
        delPtr(a);
        std::cout << a << std::endl;
        a = new A();
        delPtrRef(a);
        std::cout << a << std::endl;
}

0
0x100100080
0
0

EDIT: unnötige includes raus

Scorcher24 schrieb:

Warum mach ich das und auch andere wie man sieht?

Schlechte Bücher und Tutorials. Übergib sie der reinigenden Kraft des Feuers.

Hast du generell etwas gegen die Übergabe von Referenzen auf Pointer oder
hast du ohne genau hinzukucken das Beispiel als äquivalent eingestuft
oder ging es dir um das if(ptr!=NULL) ?

volkard schrieb:

Scorcher24 schrieb:

Warum mach ich das und auch andere wie man sieht?

Schlechte Bücher und Tutorials. Übergib sie der reinigenden Kraft des Feuers.

Hast du generell etwas gegen die Übergabe von Referenzen auf Pointer oder
hast du ohne genau hinzukucken das Beispiel als äquivalent eingestuft
oder ging es dir um das if(ptr!=NULL) ?

Es ging mir um das NULL-setzen nach delete AKA safeDelete. Das ist keine gute Idee. Praxisfern. Hilft nur gegen Fehler, die man später garantiert nicht mehr macht. Zu jedem new gehört ein delete. Allein bei dem Versuch, dafür zu sorgen, daß man nicht kein delete hat, löst man das viel leichtere Problem, nicht zwei deletes zu haben, im Vorübergehen.

Egal, wie es implementiert wird,
mit Zeiger auf Zeiger http://www.narnio.com/2007/08/17/c-safedelete-explaind/
mit Referenz und Template http://www.cpp-home.com/tutorials/48_1.htm
als Makro http://www.koders.com/c/fidF7333B272B02D9402A130F96603177E8E912E3C9.aspx?s=cdef%3Atree
oder wieauchimmer.

Das ist keine gute Idee. Praxisfern.

okay...
Dann mal nen Praxisbeispiel, wo ich sowas z.B. verwenden würde:
Ein ganz einfacher binärer Baum (mit vielen binären Knoten)
Wenn ich jetzt ein Element in einen Knoten einfügen wollte, würde ich
z.B.

right = new Node(inhalt);

machen

Später möchte ich diesen Eintrag wieder entfernen.
Dann mach ich:

delete right;
right = 0;

so garantiere ich, dass mein Destruktor mit

delete right;
delete left;

funktioniert.

Würdest du in so einem Fall anders vorgehen oder siehst du es als 'Ausnahme'

Fällt mir gerade auf... Ich hätte auch ne lineare Liste nehmen können

volkard schrieb:

Zu jedem new gehört ein delete.

Aber generell gebe ich dir da absolut recht!

Ich meine nur, dass ein

scoped_ptr<T> ptr(new T(1));
ptr.reset(new T(2));

tausendmal sicherer ist als jedes noch so "safe" delete . Und in der Regel sollte man im Anwendungscode zu Smart-Pointern tendieren, wenn überhaupt Zeiger benötigt werden (was oft nicht nötig ist).

Du hast anscheinend übersehen das in dem Code-Beispiel das er kritisiert hat eine lokale Kopie eines Pointers auf 0 gesetzt wird...

Ich denke er meinte das wxWidgets-Beispiel, oder?

Das mit der lokalen Kopie hab ich gesehen:

CSpille schrieb:

Außerdem kannst mir den Zweck von

f= NULL;

noch erklären

Hab noch nie Smart-Pointer etc. verwendet. Gab noch nie Probleme. Wobei der Code auf über 15 Jahre alt ist...

Du meinst, du hast noch keine Probleme entdeckt.

Natürlich geht es auch ohne Smart-Pointer, sieht man ja an C. Aber es wird bei komplexeren Situationen relativ lästig, besonders wenn Exceptions oder mehrere Ablaufpfade hinzukommen.

Wie löst du das? Das ist jetzt nicht einmal ein gekünsteltes Beispiel, sondern kommt ziemlich ähnlich bei mir vor. Und das Beispiel ist noch eher einfach, da alles nach dem selben Muster abläuft. Die Membervariablen sind momentan vom Typ scoped_ptr mit dem entsprechenden Zeigertypen. Die Ressourcen werfen im Konstruktor eine Exception, falls sie nicht geladen werden können.

void MyClass::LoadResources()
{
    myGraphics.reset( new GraphicResource() ); // Lädt alle Grafiken
    myAudio.reset( new AudioResource() ); // Lädt alle Sounds
    myFonts.reset( new FontResource() ); // Lädt alle Schriftarten
    myData.reset( new DataResource() ); // Lädt sonstige Daten
}

Du hast fast immer mehr und komplexeren Code, wenn du solche Probleme äquivalent ohne RAII lösen möchtest.

Ich meine nur, dass ein

scoped_ptr<T> ptr(new T(1));
ptr.reset(new T(2));

tausendmal sicherer ist als jedes noch so "safe" delete . Und in der Regel sollte man im Anwendungscode zu Smart-Pointern tendieren, wenn überhaupt Zeiger benötigt werden (was oft nicht nötig ist).

Machst du in deine Klassen eigentlich scoped_ptr<T> statt normale Pointer?
Also wo ich mir nie so die Gedanken drüber gemacht habe, was mir gerade auffällt:
Mir war ja klar, dass man im Konstruktor alles selbst aufräumen muss, falls eine
Exception fliegt. (passiert ja relativ selten ^^ - Ich weiß: falsche Einstellung)
Wenn man jetzt zwei Objekte auf dem Heap anlegt und beim zweiten eine bad_alloc
fliegt, dann hat man ja ein memory leak...
Wenn man stattdessen einen scoped_ptr verwendet jedoch nicht...

DANKE Nexus!

Ohne deine (erneute) Smart-Pointer Befürwortung wäre mir das wohl jetzt
nicht aufgefallen.

Würdest du in so einem Fall anders vorgehen oder siehst du es als 'Ausnahme'

Ich sehe das als einen ganz anderen Fall. Hier ist die Liste so definiert, daß der letzte Zeiger 0 enthält und man daran das Ende erkennt.

Mir fiel auf, daß Du im Baum Code zwei Zeilen

CSpille schrieb:

delete right;
right = 0;

geschrieben hast.

frei nach CSpille schrieb:

void removeLast()
{//ungetestet
  Node** last=&first;
  while((*last)->next!=0)
    last=&(last->next);
  delete last;
  last=0;
}

recht lustig schrieb:

void removeLast()
{//ungetestet
  Node** last=&first;
  while((*last)->next!=0)
    last=&(last->next);
  safeDelete(last);//oder wxDELETE(last);
}

Machst du in deine Klassen eigentlich scoped_ptr<T> statt normale Pointer?

Nicht scoped_ptr statt normalen Zeigern, sondern scoped_ptr statt besitz-an-sich-reissenden, nicht-teilenden Zeigern.

Wenn der Zeiger lediglich ein Verweis auf andere Daten ist, nehme ich natürlich keinen Smart-Pointer. Es gibt z.B. auch ab und zu den Fall, in dem ich einen Zeiger tief kopieren möchte. Da leider Boost und auch die Standardbibliothek nichts dergleichen bieten und Lokis Implementierung auch nur begrenzt weiterhilft, habe ich mir selbst entsprechende Smart-Pointer geschrieben, die in ihrem Kopierkonstruktor das Objekt kopieren, die virtuelle Clone() -Funktion aufrufen oder sonst was tun...

Ich sehe das als einen ganz anderen Fall. Hier ist die Liste so definiert, daß der letzte Zeiger 0 enthält und man daran das Ende erkennt.

Sehr gut...
Deine Kritik ging also gegen 'unüberlegtes' präventives setzen auf 0,
quasi als 'Allerheilmittel' für fehlende Zuordnung der Löschverantwortung

thx!