Warum nach 'delete' zusätzlich 'NULL'?

[Artchi]

Toll volkard! Warum nicht gleich so:

TStringList tZipCode();
// verarbeitung

Haste richtig toll gemacht, wirklich klasse!

[Gehirnmann!]

wo ihr grad beim gegenseitig loben seid:
gib mal das beispiel mit smartpointer (bsp.-code).
tue mich schwer mit diesen dinger wirklich zu arbeiten.. die anderen tun's doch auch!

[volkard]

Gehirnmann! schrieb:

wo ihr grad beim gegenseitig loben seid:
gib mal das beispiel mit smartpointer (bsp.-code).
tue mich schwer mit diesen dinger wirklich zu arbeiten.. die anderen tun's doch auch!

smart_ptr<TStringList> ZipCodeList = new TStringList(); 
// Verarbeitung 
//beim verschwinden smart_ptr ruft er automatisch delete auf

aber wie Artchi (lob) richtig entdeckt hat, ist

TStringList tZipCode();
// verarbeitung

noch viel cooler.

[Jester]

@artchi:

Wieso sollte er eine Funktion, die zZipCode heißte eine TStringList zurückgibt und keine Parameter nimmt, deklarieren?

[Raving Tux]

Wenn meine Klassen Pointer als Member-Variablen haben, dann setze ich diese im Destruktor immer auf NULL zurück.
Das hat mir beim Debuggen schon öfters geholfen; man erkennt einfacher, in welchem Zustand das Objekt ist: Ist es noch voll aufgebaut, oder ist es bereits halb zerstört.
Schaden kann es nicht, das konsequent zu tun; es kann allerdings öfters mal ein paar Stunden beim Debugging sparen.

Außerdem sorgt es halt dafür, daß das Programm bei jedem Durchlauf den gleichen Zustand hat. Wenn man den Pointer nicht auf NULL setzt, dann zeigt er irgendwohin. Wenn man ihn später (fehlerhafterweise) wieder verwendet, dann kann alles mögliche passieren. Wenn er dann aber auf NULL steht, dann stürzt das Programm wenigstens konsisten ab; das ist leichter zu finden, und deshalb auch einfacher zu fixen.

[volkard]

Raving Tux schrieb:

Wenn meine Klassen Pointer als Member-Variablen haben, dann setze ich diese im Destruktor immer auf NULL zurück.

im DESTRUKTOR?
uih, das ist aber spät. was soll denn nach dem destruktor noch kommen?

Das hat mir beim Debuggen schon öfters geholfen; man erkennt einfacher, in welchem Zustand das Objekt ist: Ist es noch voll aufgebaut, oder ist es bereits halb zerstört.

oder gar ganz zerstört. ok.
aber nimmt man den microsoftcompiler, überschreibt sein delete im debug-modus jeden gelöschen speicher geeignet (afair mit 0xcdcdcdcd).
daran sieht man das auch genausoschnell (auch mit schutzverletzungsgarantie).

Wenn man ihn später (fehlerhafterweise) wieder verwendet, dann kann alles mögliche passieren. Wenn er dann aber auf NULL steht, dann stürzt das Programm wenigstens konsisten ab; das ist leichter zu finden, und deshalb auch einfacher zu fixen.

eigentlich sollte der zeiger weg sein, statt auf NULL zu zeigen und noch rumzugammeln.
also im falle lokaler variablen mit dem block-zu-trick frühzeitig killen umd im falle eines attributs kann man normalerweise den zeigerhalter zu ner eigenen klasse machen, die innendrin selber delete aufruft und um die man sich gar nicht mehr kmmern muß (solange das objekt lebt, zeigt es auch auf was sinnvolles).

[volkard]

Jester schrieb:

@artchi:
Wieso sollte er eine Funktion, die zZipCode heißte eine TStringList zurückgibt und keine Parameter nimmt, deklarieren?

ich probier's mal:

//in RVO we believe
TStringList zZipCode();

[volkard]

volkard schrieb:

Jester schrieb:

@artchi:
Wieso sollte er eine Funktion, die zZipCode heißte eine TStringList zurückgibt und keine Parameter nimmt, deklarieren?

ich probier's mal:

//in RVO we believe
TStringList zZipCode();

edit: ups, hab "Wie" statt "Wieso" gelesen.
auf's "Wieso" ist die antwort "Weil man damit aufbaz der liste von der verarbeitung trennt. vermutlich zu schlimmen übergabekosten, TStringList zZipCode(ZipLib* zl,char* currentDir,char* currentDevice,char* fileName,SecurityContext* sc,char* userName,char* password,FileViewOtions* fvw);
ok, wenn sie keine parameter nimmt, isses wohl quatsch.

[RHBaum]

@Volkard

aber nimmt man den microsoftcompiler, überschreibt sein delete im debug-modus jeden gelöschen speicher geeignet (afair mit 0xcdcdcdcd).
daran sieht man das auch genausoschnell (auch mit schutzverletzungsgarantie).

Du predigst hier aber jetzt nicht grad fuer ne sehr von nem Hersteller abhaengige Loesung oder ....

Allein um davon unabhaengig zu werden, wuerde ich mir die huerde von zigtausend Null zuweisungen gern aufbuerden

Der einzige C++ like weg Imho sind smartpointer, oder die davon abgeleiteten (sinnbildlich, aggregation waer nen besserer weg), noch maechtigeren (selbstgeschriebenen) Wrapper ... !!!

Ciao ...

[rüdiger]

Der einzige C++ like weg Imho sind smartpointer, oder die davon abgeleiteten (sinnbildlich, aggregation waer nen besserer weg), noch maechtigeren (selbstgeschriebenen) Wrapper ... !!!

selbst geschriebene Wrapper? Drei Ausrufzeichen? Ich bin verwirrt.

Ein Smart Pointer ist ja nicht eine bestimmte Klasse, die Smart Pointer Klasse, sondern einfach ein Design Prinzip, was eine Klasse beinhält, egal ob sie smart_ptr, auto_ptr, shared_ptr, scoped_ptr oder SmartPointer etc. heisst.

[borland-hasser]

Soweit ich weiß lassen sich die Borland Klasse nur auf dem Heap anlegen.

[otze]

borland-hasser schrieb:

Soweit ich weiß lassen sich die Borland Klasse nur auf dem Heap anlegen.

hm? wenn ich deinen satz richtig interpretiert hab, und du die vcl klassen meinst: nö, das stimmt so nicht

[Ringding]

otze schrieb:

hm? wenn ich deinen satz richtig interpretiert hab, und du die vcl klassen meinst: nö, das stimmt so nicht

[C++ Error] Unit1.cpp(20): E2459 VCL style classes must be constructed using operator new

[volkard]

RHBaum schrieb:

Du predigst hier aber jetzt nicht grad fuer ne sehr von nem Hersteller abhaengige Loesung oder ....

oh, doch!
meinetwegen mögen die nicht-ms-hörigen sich ihr globales new/delete überladen, daß es ähnliches tut. aber der anwendungscode muss einigermaßen schrottfrei bleiben.

[Gast]

Es ist ja in dem Sinne keine herstellerabhängige Lösung sondern eher eine herstellerabhängige zusätzliche Sicherheit und die auch nur im Debug-Build.

[RHBaum]

@ Optimizer
Ja, haette eher schreiben sollen ... "du verleasst dich auf ein Herstellerabhaengiges, nicht genau spezifiziertes, und in den Dokus gut verstecktes Feature" Ist auch nicht wirklich ne Loesung, eher ne eigenheit. Und ja, Ich muesste wissen, das bei M$ die Begriffe "Lösung" und "Problem" meist sehr beieinander liegen

@ kingruedi
Ja klar sind smartpointer nen Software Design
Und je nach anwendungsfall sollt man auch unterschiedliche Smartpointer nutzen .... Wrapper sind nen noch allgemeineres Design, lassen sich aber mit Smartpointer gut combinieren ...
Und hier gehts ja grad nur um design ....
Was ich mein ist, fuer Arbeiten mit zeigern, also dynamisch erzeugen objekten, sind wrapper, die die Funktionen am Zeiger wrappen und sich um die verwaltung des zeigers auch noch kuemmern(intern durch smartpointer), die sauberste Sache. DIe meisten zeiger sind nie so allgemein, dass man nicht auf die idee kommen wuerd, da gleich die funktionalitaet mit durchzureichen ....
In den meisten C++ programmen fliegen noch viel zu viel lose Zeiger rum ....

Ciao ...

[rüdiger]

@RHBaum
aus dem Grund kann man doch den -> Operator überladen, was eigentlich alle SmartPointer tun, die ich für C++ kenne. Wenn man einen WrapperSmartPointer hat, dann sorgt man IMHO nur für mehr Abhängigkeiten und wenn man irgend etwas spezielles anpassen muss, zeigt doch der Modern C++ Design SmartPointer eindeutig, wie man das wunderbar via Policies lösen kann.