Sauber Programmieren: Variablen zurücksetzen?

[Rakshasa]

Hallo!!

Ist es eigentlich notwendig, die verwendeten Variablen eines begin...end am Schluss manuell zurückzusetzen, also z.B. so:

Delphi-Quellcode:

Procedure MeineProcedure;
var
s: String;
i: integer;
myarray: Array of TString;
begin

// code code code code


s := '';
i := -1;
SetLength(MyArray, 0);

end;

Oder macht Delphi das ausreichend von alleine?

[edit=alcaeus]code- durch delphi-Tags ersetzt. Bitte in Zukunft die richtigen Tags verwenden, Danke. Mfg, alcaeus[/edit]

[brechi]

variablen innerhalb einer prozedur werden auf den stack abgelegt wenns nicht gerade ein string ist
aber da macht delphi das auch noch selber

einzigst bei komponenten die du erzeugst, die solltest du mit .free wieder freigeben

[sniper_w]

Zitat:

die solltest du mit .free wieder freigeben

Vielleicht besser wäre es:

Delphi-Quellcode:

FreeAndNil(MyObj);

[BlackJack]

sollte man ein dynamisches array nicht auch besser wieder auf die länge null setzen (und eventuell noch finalize'n)?

[Hansa]

Das da geht in Richtung lokale/globale Variablen ! Woher soll denn das arme Programm wissen, was noch passiert ? Die Variablen müssen also nicht "zurückgesetzt" werden, sondern nur richtig initialisiet werden beim Programmstart.

[BlackJack]

Zitat:

Zitat von Hansa

Die Variablen müssen also nicht "zurückgesetzt" werden, sondern nur richtig initialisiet werden beim Programmstart.

naja das kann ich jetzt so nicht unterschreiben. auf jeden fall muss man bei lokalen variablen (also in proceduren etc.) alles an speicher was man sich selber holt auch wieder selber freigeben, also Create/Free, New/Dispose, Initialize/Finalize, GetMem/FreeMem etc., weil ansonsten speicerlecks entstehen würden, da ja nach verlassen der procedure die zugriffsadresse, die in einer lokalen variable gespeichert ist, futsch wäre.

aber "einfache" lokale variablen (wie z.b. Integer, Chars, statische Arrays etc) muss man nicht wieder auf einen standardwert setzen, da die variablen eh im stack liegen, der nach verlassen der procedure eh nichtmehr erreichbar ist.

[Hansa]

Zitat:

Zitat von BlackJack

...naja das kann ich jetzt so nicht unterschreiben..

Doch. :mrgreen:

[Pseudemys Nelsoni]

Zitat:

aber "einfache" lokale variablen (wie z.b. Integer, Chars, statische Arrays etc) muss man nicht wieder auf einen standardwert setzen, da die variablen eh im stack liegen, der nach verlassen der procedure eh nichtmehr erreichbar ist.

Ich glaube, das sind auch die Typen, auf die Hansas Post bezogen war.

[BlackJack]

naja ein "array of TString" gehört da ja nicht unbedingt dazu, und das muss man sogar in zweifacher hinsicht freigeben - erst die TStrings einzeln, und dann noch das array auf Länge null setzen.

[Phoenix]

Zitat:

Zitat von BlackJack

naja ein "array of TString" gehört da ja nicht unbedingt dazu

Die TSTringList hingegen schon, und wer ein Array anstelle von der nutzt ist gerade selber schuld. :tongue:

[Robert Marquardt]

"array of" und string werden ausschliesslich auf dem Heap alloziiert.
Delphi implementiert daher ein heimliches try finally, um die lokalen Variablen zu initialisieren und finalisieren.

Delphi-Quellcode:

var
  Bla: array of Integer;
begin
  try
     Bla := nil; // das sind Null Elemente
     ....
     // Userteil der Funktion
  finally
     SetLength(Bla, 0); // das dealloziiert die Variable und setzt auf Null Elemente = nil
  end;
end;

Bei globalen Variablen legt Delphi zusaetzliche initialization und finalization Sections an, um das zu erledigen.
Man sollte daher globale, getypte und initialisierte Konstanten-Arrays mit Strings vermeiden. Meist genuegt es PChar zu verwenden.
Delphi spart sich dann die Sections und wandelt die PChars erst in Strings um wenn man sie benutzt.

[Hansa]

Irgendwelche Variablen sollten vor der ersten/erneuten Benutzung initialisiert werden ! Wenn es lokale Variablen sind, dann nützt es nichts, diese "zurückzusetzen", denn bei einem erneuten Aufruf einer Prozedur sind sie eventuell doch wieder undefiniert !

Ansonsten wäre eben nur der Ausweg, sich mit den Speicher-Eingeweiden von Delphi rumzuschlagen. Das würde ich mir aber ersparen und grundsätzlich den Weg einer sauberen Initialisierung wählen.

[sniper_w]

Auf jedem Fall sollte man im Kopf haben, dass nach Obj.Free; immer Obj := nil; kommt oder einfacher FreeAndNil(Obj);. Denn sollte man später mit Assigned überprüfen ob ein Objekt noch "da" ist, so könnte man falsche ergebnisse bekommen und somit eine AV ;).

Zitat:

Use Assigned to determine whether the pointer or procedure referenced by P is nil. P must be a variable reference of a pointer or procedural type. Assigned(P) corresponds to the test P<> nil for a pointer variable, and @P <> nil for a procedural variable.

Assigned returns False if P is nil, True otherwise.

Note: Assigned can't detect a dangling pointer--that is, one that isn't nil but no longer points to valid data. For example, in the code example for Assigned, Assigned won't detect the fact that P isn't valid.

[jbg]

Zitat:

Zitat von sniper_w

Auf jedem Fall sollte man im Kopf haben, dass nach Obj.Free; immer Obj := nil; kommt oder einfacher FreeAndNil(Obj);.

Bei lokalen Variablen ist das völlig unnütz und verlangsamt, wenn auch nur sehr gering, die Ausführgeschwindigkeit. Warum sollte man eine Variable, die von anderen Daten auf dem Stack nach dem Verlassen der Funktion überschieben wird, noch auf nil setzen? Auf diese lokale Variable kann ja sowieso nicht mehr zugegriffen werden, da der Compiler einen Syntaxfehler ausgibt, wenn man in Funktion A auf die lokalen Variablen der Funktion B zugreifen will.
Und wer meint, der müsse mittels ESP auf diese bereits als ungültig deklarierten Daten zugreifen, der wird sich sicherlich mehr Gedanken machen, wie er mit lokalen Variablen umzugehen hat.

Ich persönlilch nutze FreeAndNil nur dann, wenn nicht vorhersagbar ist, dass irgendetwas noch darauf zugreifen könnte. So ist es bei Controls im Desktruktor oft nötig FreeAndNil zu benutzen und in den Methoden Resize, Paint, ... eine Abfrage einzubauen. Aber bei plain Objekten mache ich das nur in ganz seltenen Fällen.

[sniper_w]

Zitat:

Ich persönlilch nutze FreeAndNil nur dann, wenn nicht vorhersagbar ist, dass irgendetwas noch darauf zugreifen könnte.

So war´s auch gemeint.

[Rakshasa]

Hm, danke für die aufschlussreichen Antworten bisher!!!! :)

Ich fasse mal zusammen:

"Einfache" Variablen (z.B. String, Char, Integer) müssen nicht zurückgesetzt werden, eigene Typen oder Arrays aber schon, also z.B. .free oder SetLenght(xxx,0) oder FreeAndNil().

:)

[Khabarakh]

Zitat:

Zitat von Rakshasa

eigene Typen

Eigene Klassen :wink:, eben alle zur Laufzeit instanziierten, die kein Parent haben, kein Item einer TObjectList (AOwnsObject = true) sind oder sonstwie verwaltet werden.

Zitat:

oder Arrays

Laut Robert Marquardt erledigt das Delphi.

[BrunoT]

Hi

noch 'ne Frage dazu:

ich erzeuge ein Array of TButton mit Form als Parent. Beim Verlassen des Programms muss ich die Buttons nicht frei geben oder? :gruebel:

mfg

BrunoT