![]() |
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Toller Beitrag himitsu
Macht vieles verständlich; |
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Hach ja, Init und Done.
Es gibt einen Compilerschalter im FPC, der bewirkt, dass alle Konstruktoren Init und alle Destruktoren Done heißen müssen. Wahrscheinlich hat der Threadersteller die Namen daher. Ich bin über den Schalter auch mal eher zufällig gestoßen. Ich wusste damals gar nicht, dass es den überhaupt gibt, geschweige denn, dass ich ihn eingeschaltet hatte. Und dann habe ich mich immer gewundert, wieso der FPC kein Create und Destroy nimmt. Und deshalb kommen Init und Done auch in manchem meiner Codes vor. Wollte hiermit nur sagen: So selten ist die Init/Done-Konvention gar nicht. Meistens wird Create/Destroy verwendet, aber öfters eben auch mal Init/Done. |
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Zitat:
Man kann 'destroy' aufrufen. Ohne Probleme. Wenn man sich seiner Sache sicher ist. Hie z.B.
Delphi-Quellcode:
MyObject := TMyObject.Create;
Try MyObject.Do; Finally MyObject.Destroy; // <-- Ich kann sicher sein, das MyObject instantiiert ist. End; Zitat:
Der einzige Grund 'Free' aufzurufen, ist doch der: Wenn man mal 'Free' und mal 'Destroy' verwendet, ist das nicht sauber. Da Free bei unsauberer Programmierung robuster ist, verwenden wir eben immer Free. Außerdem machen das Alle. Und wenn man wirklich rumschlampen will, nimmt man eben immer 'FreeAndNil'. Dann ist man entgültig auf der sicheren Seite. Man produziert zwar überflüssigen Code, aber wem das egal ist, bitte sehr. Bitte nicht falsch verstehen: FreeAndNil ist manchmal sehr praktisch aber eben nicht immer. |
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Warum willst du unbedingt Destroy verwenden?
Bzw., was ist soooo schlimm an Free? PS: Free > FreeAndNil Destroy > DestroyAndNil :?: |
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Zitat:
Der Schalter: Zitat:
|
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Zitat:
Ich mache aber auch mal Fehler und dabei ist es von unschätzbarem Wert, wenn ich überall FreeAndNil benutzt habe. Wenn dann nämlich (egal ob in eigenem oder fremden Code) durch einen Fehler nach der Freigabe auf einen Pointer zugegriffen wird oder ähnliches, sieht man das sofort statt (besonders bei fremdem Code) stundenlang suchen zu müssen, weil irgendwo Speicher überschrieben wird... Ich habe schon oft genug fremden Code, z.B. aus diversen Open Source Projekten, debuggen müssen. Und wenn dort dann irgendwo Schutzverletzungen aus solchen Gründen auftreten, dann suche einmal woher der ungültige Pointer kam. Und das nur, weil eben nur das Objekt freigegeben wurde, aber der Pointer nicht auf nil gesetzt wurde... :roll: Dann bin ich z.B. vor einigen Monaten bei einem solchen Problem in einer Komponentensammlung einmal durchgegangen und habe per RegEx an ca. 1000 Stellen Free durch FreeAndNil ersetzt und hatte dann das Problem in wenigen Minuten gefunden... (nachdem ich vorher schon eine ganze Weile erfolglos debuggt hatte...) |
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Ich verwende auch i.d.R. FreeAndNil, eben weil der Zeiger dann auch zurückgesetzt wird (und nicht nur der Speicher freigegeben).
Schön wäre, wenn durch Free der Zeiger automatisch auf nil gesetzt würde (ich würde da so argumentieren, wie es auch ein Anfänger betrachtet: Das Objekte ist zerstört, also ist es nicht mehr da (und zeigt nicht mehr auf einen Speicherplatz)) und auch alle weiteren Referenzen auf das freigegebene Objekt - aber das wäre dann ja wieder ein anderes Thema ;-) |
AW: Verunsicherung mit Destructor, Free und FreeAndNil
Ach, das elende Thema FreeAndNil mal wieder... halte ich nur für sinnvoll, wenn man irgendwo anders noch mit dieser (und genau dieser) Objektreferenz weiterarbeitet (und diese auch mit Assigned abprüft).
Folgendes bringt zum Beispiel garnüscht:
Delphi-Quellcode:
In der Praxis wäre dieser Code natürlich nicht so vorhanden, es soll nur gezeigt werden, was FreeAndNil nämlich nicht macht: alle Referenzen auf besagtes Object auf nil zu setzen, damit nix schief gehen kann. Schleppt man irgendwo diese Objektreferenz mit sich rum (zum Beispiel in einem anderen Objekt oder in einer Liste) hat man garnix gewonnen außer nem trügerischen ruhigen Gewissen.
o1 := TMyObject.Create;
o2 := o1; FreeAndNil(o1); if Assigned(o2) then o2.Free; // <- boing! Invalid pointer operation An dieser Stelle muss ich mal FredlFesl zustimmen - das Argument: "dann bin ich auf der sicheren Seite" ist für mich an dieser Stelle gleichzusetzen mit: "ich hab keinen Plan mehr, was mein source macht und ich hab auch keine Tests, deshalb code ich so, dass möglichst wenig kaputt gehen kann" (die nutzung von Fremdcode lass ich mal außen vor, das ist ein anderes Thema) Übrigens FreeAndNil benutzt einen var parameter (logisch, wie soll auch sonst diese Variable auf nil gesetzt werden). Also ist die Nutzung schon vornherein eingeschränkt (nicht nutzbar mit Properties oder non var Parametern) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz