Aus dem gleichen Grund verwende ich "FreeAndNil" nicht. Ich will in meinem Code nicht gefragt werden: "Wieso machst Du das denn hier? Das ist überflüssig"
Gerade FreeAndNil ist an vielen Stellen sehr wichtig. Nämlich immer dann, wenn man später wissen will, ob das Objekt schon erzeugt wurde. Auch ein zweiter Aufruf an Free knallt sonst.
Korrekt, aber dann ist mein Programm ja falsch. Ein fehlerfreies Programm benötigt kein FreeAndNil!
Ein Beispiel ist hier das Singleton-Pattern. Wie willst du denn wissen, ob das Objekt existiert, wenn du es nicht auf nil prüfen kannst?
Hmmm. Bei meinem Singleton-Pattern brauche ich das nicht und wenn, wäre es ein sinnvoller Einsatz. Ich sag ja nicht, das man es NIE benötigt, sondern nur NICHT IMMER. TRY-FINALLY braucht man auch, aber NICHT IMMER...
Anderes Beispiel: Grundsätzlich eine Variable initialisieren: Stört nicht, wird eh wegoptimiert und ist robust. Und überflüssig und blöd.
Wenn eine lokale Variable nicht initialisiert wird, ist es russisches Roulette was dabei herauskommt.
Bitte lesen... "wird eh wegoptimiert" gilt ja wohl nicht für deinen Fall.
Ich rede von Grundsätzlich und Du kommst mit einzelnen Beispielen, wo es sinnvoll ist. Tut mir leid, das widerlegt meine Behauptung nicht ("Ausnahmen bestätigen die Regel"). Und: Ja natürlich gibt es Szenarien, wo ein FreeAndNil oder eine Variableninitialisierung wichtig ist. Ich bin ja nicht von Gestern.
Nur lese ich oft, das man
immer FreeAndNil verwenden sollte, weil es ja nicht schadet. So ein Blödsinn.
Genauso blödsinnig wie: Variablen müssen immmer, d.h. ohne Nachdenken, initialisiert werden. Quatsch.
Oder eben: Create...Free (sorry: FreeAndNil) gehört immer zusammen mit einem Try-Finally.
Mich stört das "immer", weil es gleichbedeutend ist mit "ohne Nachdenken".
Klar: Ist immer noch besser als die Aussage: "Vergiss Try-Finally, das ist nur was für Angsthasen".
Also: In meinen Anwendungen steht dort, wo es nötig ist (und nur dort) Try-Finally.
FreeAndNil verwende ich nicht, denn meine Objekte werden nicht doppelt freigegeben. Letzteres habe ich mir so angewöhnt, es mag eine Marotte sein, aber seit dem laufen die Programme einfach besser: Vor allen Dingen sagt mir FastMM4, ob ich nicht aufgepasst habe.
Variablen werden nur dort initialisiert, wo es sinnvoll ist. Ich prüfe meine Anwendungen bis zum Release immer mit FastMM4, d.h. die ersten paar Monate laufen sie mit allen Prüfungen von FastMM. Erst wenn nix mehr passiert, deaktiviere ich die Reporting-Features.
[/QUOTE]Besser lesbar sind definierte Anfangswerte aber definitiv[/QUOTE] Das lasse ich gelten.