Sinn & Funktion Initialisierungs-/Finalisierungsteil

[himitsu]

Kurz gesagt:
- in initialization kann man lokale Variablen initialisieren oder andere Funktionen ausführen, welche bei Programmstart ausgeführt werden müssen
- in finalization genau das Gegenteil, also lokale Variablen freigeben (z.B. für Pointer und Objekte) und abschließende Prozeduren ausführen

Zitat von hannes2011:

Muss ich nun den Initialisierungsteil noch mit begin & end bestücken oder nicht? Da fängts ja schon an....

Muß nicht, aber kann.

Begin-End kann man eigentlich überall im Code einfügen:
(diese kann man im Prinzip auch nehmen, um Codeblöcke optisch zu trennen)

Delphi-Quellcode:

procedure Test;
begin
  begin
    begin
      WriteLn('123');
    end;
    WriteLn('456');
  end;
  begin
    WriteLn('789');
  end;
end;

Delphi-Quellcode:

...
initialization
  WriteLn('start');

finalization
  begin
    WriteLn('ende');
  end;

end.

Zitat von hannes2011:

Ich dachte mir - laienhaft -, dass ich einfach mal eine Prozedur in den Initialisierungsteil packe & eine in den Finalisierungsteil.
Funktioniert natürlich nicht - war ja klar -.-.

Geht schon:
Die Prozeduren kommen in implementation und diese kannst du dann in initialization oder finalization aufrufen.


Die Abschnitte innerhalb von, bzw. hinter/unter initialization, finalization und begin (in der DPR) sind wie die Funktionsrümpfe zu verwenden, also so also würden sie schon zwischen einem begin-end liegen.

[Hawkeye219]

Hallo,

Zitat von Sir Rufo:

// Hier nix mit initialization oder finalization

Jein. Der Teil zwischen begin und end in einer .dpr-Datei ist der Initialisierungsteil. Zu Zeiten von Turbo Pascal war das auch in Units die einzige Möglichkeit, Initialisierungen vor der Ausführung des eigentlichen Hauptprogramms durchzuführen (das funktioniert übrigens auch heute noch). Eine Finalisierung gab es damals nur mit Hilfe der Exit-Routinen.

Gruß Hawkeye

[hannes2011]

Delphi-Quellcode:

unit unit2

var
 Spielliste : tstringlist;

..............

Da erklärt der mir leider, dass tsringlist nen undefinierter Bezeichner ist...hmmm...was hab ich da nun falsch gemacht bzw. woran hab ich nicht gedacht?

Danke schon mal *zugeb*

[Alter Mann]

Hi,

das Problem mit TStringList ist aber eine andere Frage!!!

Zum ursprünglichen Problem, bei der Verwendung von Com-Objekten ist die Nutzung
von initialization und finalization recht Praktisch:

Delphi-Quellcode:

initialization
  CoInitialize(nil);

finalization
  CoUninitialize;

Ansonsten, wenn Fragen dazu sind, bitte in der Hilfe nachlesen, dort ist es eigentlich gut erklärt.

Schönen Abend noch.

[Dezipaitor]

Das CoInitialize kann da aber schon zu spät sein, weil z.B. ComServ schon vorher eingebunden wird und da wird das bereits gemacht. Außerdem ist der Aufruf von CoUnitialize problematisch, wenn irgendjemand noch COM benutzt. Wenn soetwas der Fall ist, dann geht CoUnitialize in eine Schleife und wartet solange, bis COM fertig ist.
Ich würde empfehlen, Co(Un)itialize nur im Hauptprogramm (und Threadfunktionen) zu verwenden, damit man 100% Kontrolle besitzt. So kann man noch noch CoUnitialize alle Interfaces schließen und muss nicht suchen, in welche Unit das gemacht werden soll. Außerdem kann die Benutzung in externen Bibliotheken noch viel größere Probleme bereiten.
Oh man, das musste ich alles erleben, als ich JwsclComSecurity für JWSCL geschrieben habe.

Im Endeffekt gilt für Initialization und Finalization, dass je lokaler die Auswirkungen sind, desto geeigneter ist der Platz dafür. Wenn also andere Units (und womöglich Threads) abhängig sind von solch einer Variablen, dann muss man schon sehr gut planen, damit das alles funktioniert.

[mjustin]

Zitat von hannes2011:

Der Sinn des Initialisierungszeil ist eigentlich klar - es sollen Operationen durchgeführt werden, die nur einmal zum Start des Programms ausgeführt werden. Für den Finalisierungsteil bedeutet das natürlich, dass dann die Operationen zum Ende des Programms gemeint sind.

Interessant ist für eine Abhandlung zu diesem Theam noch die Reihenfolge, in der initialization und finalization über mehrere Units hinweg ausgeführt werden (und welche bösen Dinge dann geschehen können, wenn man eine bestimmte Reihenfolge erwartet und später 'versehentlich' die unit-Abhängigkeiten ändert...)

[himitsu]

Die Finalisierungen werden in umgekehrter Reihenfolge abgearbeiter, wie ihre Units initialisiert wurden.

Und Units, welche im Interface eingebunden wurden, werden immer davor initialisiert und demnach auch erst hinterher finalisiert (also im Vergleich zu der Unit, in welcher die entsprechende Unit eingebunden wurde)

!!! eine im Implementationsteil eingebundene Unit kann davor oder danach initialisiert werden.

Also ist es schon möglich, daß man mit Sicherheit eine verhältnismäßige Reihenfolge voraussetzen kann,
wenn man gewisse Punkte beachtet.