ich habe eine Klasse mit

// xyz.h

class xyz

{

CMySocket* sock;

}

// xyz.cpp


void xyz::einefunktion()

{

if (dies und jenes)

{

sock = new CMySock();

}

}

wenn jetzt dies und jenes nicht zutrifft, und ich den destrucktor aufrufe, dann knallts - logisch.

xyz::*xyz()

{

delete sock;

}

kann wie löse ich das wohl am besten?

TinTin

Initialisiere sock im Konstruktor mit Null. delete 0 tut nichts.

danke, dass passt. ist schon ein kreuz mit den nicht initialisierten variablen.

Goldene C++ Regel:

Im Destruktor IMMER auf Null prüfen! delete setzt den Pointer auch auch Null.

if (ptrSomething != null)

{

delete ptrSomething;

}

Goldene C++ Regel:

Im Destruktor IMMER auf Null prüfen!

Unnötig, da delete NULL nichts tut.

delete setzt den Pointer auch auch Null.

Falsch. Delete ändert den "Wert" des Zeigers nicht.

Oh sorry, C++ ist lange her, hab ne Zeile vergessen, so wars:

if (ptrObj != null)

{

delete ptrObj;

ptrObj = null;

}

Es gab mal ein dolles Buch von Kernighan und Ritchie mit C++ Best Pratices. Das ist deswegen sinnvoll weil du evtl. 2 Millionen Objekte hast - was im besten Fall dazu führt das dieser Codeblock 2 Millionen mal ausgeführt wird. Delete wird intern wie ein Methodenaufruf gehandelt, führt also zu einem push/pop in Assembler was für die Perfomance ungünstiger ist als 2 Millionen Compares.

Aber egal, du hast Recht, initialisieren sollte man natürlich sowieso... :e@sy

Delete wird intern wie ein Methodenaufruf gehandelt, führt also zu einem push/pop in Assembler

Delete kann wie jeder andere Methodenaufruf geinlinet werden.

was für die Perfomance ungünstiger ist als 2 Millionen Compares.

Kannst du nicht wissen. Es kommt hinzu, dass delete diesen Compare sowieso nochmal macht. Damit wird es zu einer statistischen Betrachtung. Wie oft kommt da ein Nullzeiger vor?

Das if kann ja nur dann überhaupt einen Vorteil bringen, wenn der Zeiger tatsächlich Null ist. Die Frage ist also nicht, wieviele Objekte du hast, sondern wieviele du nicht hast.

Was das Nullsetzen nach dem delete angeht, auch darüber kann man geteilter Meinung sein. Sinnvoll ist es, wenn ein Zeiger "recycled" wird, also während seiner Lebenszeit immer wieder mal auf ein Objekt zeigt, zwischendurch aber auch mal nicht.

Bei einem Memberzeiger, mit dem das nicht passiert, ist das IMHO unsinnig. Mit der gleichen Argumentation könnte man int-Member im Destruktor auf 0 setzen - macht doch auch niemand.

Meiner Meinung nach ist der Grund für das Nullsetzen von Zeigern einfach der, dass dieses Konstrukt sehr schön vor Abstürzen durch doppelte deletes schützt. Aber damit verdeckt man IMHO nur ein schlimmeres Problem. Denn wie kann es überhaupt zu einem doppelten delete kommen: Doch nur dadurch, dass man in der Designphase die Lebenszeiten und Besitzverhältnisse der Objekte nicht ordentlich festgehalten hat.

Ich rate von solchen Konstrukten ab, weil sie IMHO schlampiges Design fördern.

Meiner Meinung nach ist der Grund für das Nullsetzen von Zeigern einfach der, dass dieses Konstrukt sehr schön vor Abstürzen durch doppelte deletes schützt. Aber damit verdeckt man IMHO nur ein schlimmeres Problem. Denn wie kann es überhaupt zu einem doppelten delete kommen: Doch nur dadurch, dass man in der Designphase die Lebenszeiten und Besitzverhältnisse der Objekte nicht ordentlich festgehalten hat.

Jein. Angenommen ich hab eine Klasse welche unter anderem irgendwelchen Speicher reserviert. Außerdem biete ich dem Aufrufer eine Methode an um diesen Speicher wieder freizugeben, sobald er diesen nicht mehr benötigt aber das Object was noch irgendwas anderes enthält weiterbenutzen will.

Wenn ich dabei den Zeiger nicht auf 0 setzen würde könnte ich ja im Destruktor nicht feststellen ob der Aufrufer der Klasse das schon freigegeben hat oder ich das noch machen muss.

Von daher würde ich sagen das es je nach Anwendungsfall schon richtig ist das zu machen.

Wobei du natürlich recht hast das es im Destruktor nichts außer ner unötigen Zuweisung bringt