Löschen der Klasse aus einer Funktion

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.

Scorcher24 schrieb:

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

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.

Scorcher24 schrieb:

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

Scorcher24 schrieb:

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

Nexus

Scorcher24 schrieb:

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

volkard

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");

volkard schrieb:

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.

Nexus

Scorcher24 schrieb:

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

Fellhuhn

if ( ptr != NULL )
        {
            delete ptr;

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

Nukularfüsiker

Scorcher24 schrieb:

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

volkard

Scorcher24 schrieb:

Warum mach ich das und auch andere wie man sieht?

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

Scorcher24 schrieb:

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

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) ?

volkard

CSpille schrieb:

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.

volkard schrieb:

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!

Fellhuhn

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

Nexus

Natürlich gibt es Fälle, wo man Zeiger nach dem Freigeben auf Null setzt. Doch wenn man kein Containerbastler ist, tritt das meines Erachtens eher weniger auf. Ich weiss nicht, wann ich sowas das letzte Mal benötigt habe. Selbst ein selbstgeschriebenes delete ausserhalb einer Smart-Pointer-Implementierung ist schon länger her.

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

Fellhuhn

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

Fellhuhn schrieb:

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

Nexus

Fellhuhn schrieb:

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.