Verständnisfrage zu Unit: Initialization und Finalization

[Assertor]

Hallo,

ich bin grad am Überlegen, "wie oft" die Initialization und Finalization einer Unit aufgerufen wird.

Meine Unit steht in verschiedenen Forms und nimmt auch Anpassungen an Application.Irgendwas und den Screen.Cursors vor. Ich möchte natürlich Overhead vermeiden...

Ein einfacher "Beep"-Test bei dem ich ein Beep in der Initialization eingebaut hatte brachte nur "ein Beep" (Zitat "Geben Sie mir ein Ping" ;).

Was sagt Ihr?

Gruß + Danke
Winkel79

[Robert Marquardt]

Initialization und finalization werden bei Programmstart respektive Programmende genau einmal aufgerufen. Die Reihenfolge hat Delphi beim Kompilieren ausgerechnet.

[Assertor]

Hallo und Danke Robert,

Zitat:

Zitat von Robert Marquardt

Initialization und finalization werden bei Programmstart respektive Programmende genau einmal aufgerufen. Die Reihenfolge hat Delphi beim Kompilieren ausgerechnet.

Gilt das auch für die Wiederverwendung der Unit für andere Zwecke in anderen Forms (hier im Implementation-Teil):

Zitat:

Zitat von Delphi OH

Der initialization-Abschnitt
...
Für Units in der uses-Liste von Interfaces werden die von einem Client verwendeten initialization-Abschnitte von Units in der Reihenfolge ausgeführt, in der Units in der uses-Klausel des Clients aufgeführt sind.

Ich schließe aus dem "Interfaces": Ja.

Zur Erklärung: Ich habe alle Kompatibilitätsfunktionen in eine Unit gepackt. Hier werden per Initialization die OS-Bedingungen abgefragt, die eigene Dateiversion ausgelesen, Cursor und Hints/Tooltips an Vista angepasst, VistaAltFix und TaskBarFix etc.pp.

Zusätzlich enthält die Unit Basisfunktionen, wie z.B. ein Ansi/Unicode-ShellExecuteAndWait etc.

Ich möchte natürlich, daß die Anpassungen und der VistaAltFix nur einmal instanziert werden - auch um Zeit und Ressourcen zu sparen. Ich bin jetzt schon mal mit dem SamplingProfiler (1.4.irgendwas) rangegangen, aber weiß auf die schnelle nicht, wie man das gescheit prüfen könnte.

Gruß winkel79

[Phoenix]

Zitat:

Zitat von Robert Marquardt

Die Reihenfolge hat Delphi beim Kompilieren ausgerechnet.

Jain, das ist nicht so ganz richtig.
Die Reihenfolge bestimmt sich aus der Reihenfolge, in der die Units im Projekt verwendet werden.
Wenn z.B. die Anwendung Form 1 und Form verwendet, und Form1 verwendet Unit1 und Unit2 und Form 2 verwendet Unit1 und Unit3, dann ist die Reihenfolge entsprechend: Unit1 (aus Form1 inkludiert), Unit2 (aus Form1 inkludiert), Form1 (erst jetzt, weil ja schon Initialized-Objekte aus Unit1 und Unit2 benutzt werden könnten), Unit3 (aus Form2 inkludiert), Form2 - das jetzt auch auf Initialisierte Objekte der Units 1 und 3 zugreifen kann.

[Robert Marquardt]

Nur genau einmal. Wie oft die Unit im Programm verwendet wird hat damit nichts zu tun.
Beim Programmstart werden die initialization Sections der Reihe nach abgearbeitet (entsprechend die finalization Sections beim Programmende).

Welche Unit welche andere Unit verwendet beeinflusst nur die Reihenfolge der Abarbeitung. Das wird zur Kompilationszeit entschieden (es ist vollstaendig entscheidbar). Bei Programmausfuehrung ist die Reihenfolge also immer gleich.

Forms sind normale Objekte, die sowieso erst nach Ende der Initializaton erstellt werden koennen.Erst dann kommt der Code im .dpr dran.

[Robert Marquardt]

Phoenix, genau das sage ich ja. es wird beim Kompilieren des EXEs ausgerechnet (im Rahmen der Codegenerierung) wie die Reihenfolge zu sein hat.

[Assertor]

Das ist zwar sehr informativ, aber um die Frage kürzer (einfacher) zu machen:

Wir der Initialization-Teil einer Unit nur -genau einmal- ausgeführt unabhängig davon, ob andere Units und/oder Forms diese Unit ebenfalls verwenden?

Dann versteh ich die Antwort auch, ohne einen weiteren Kaffee ;)

Danke :zwinker:
Gruß winkel79

[Robert Marquardt]

JA!

[Assertor]

Zitat:

Zitat von Robert Marquardt

JA!

Danke, Robert. Das ist absolut eindeutig ;) Obwohl, jetzt lese ich mir Eure Diskussion nochmal durch, der Kaffe ist gerade fertig.

:dp:

Gruß winkel79

Edit: Nun ist der Groschen gefallen. Wobei dies eher die Funktionsweise bzw. "Intelligenz" des Compilers beschreibt. Ich fand nur, daß die Delphi OH sich - wie so oft - einer relativ undeterminierten Sprache bedient. Danke Euch beiden!

[Prakti16]

Ich weiß dieses Thema ist alter aber ich habe dazu eine Frage.
Und zwar wie ich eine Initialization und Finalization schreibe ich habe mich da durch gelesen aber ich bin ein Anfänger und habe es nicht so richtig verstanden.
könnte mir jemand einen kurzen Quelltext darüber schreiben als beispiel damit ich es zu mindest um den Text zu verstehen darüber ein Beispiel bekommen ( wenn es geht bitte vereinfacht ).
Danke wenn das jemand ließt und meine frage beantwortet

[DeddyH]

Initialization und Finalization kommen vor das abschließende "end." der entsprechenden Unit. Innerhalb dieser kannst Du nur auf "globale" Dinge zugreifen, z.B. globale Variablen initialisieren. Die Abschnitte werden aufgerufen, sobald die enthaltende Unit eingebunden wird bzw. als letztes bei Programmende (vereinfacht ausgedrückt).
Beispiel (aus dem Hut, kann daher Fehler enthalten):

Delphi-Quellcode:

unit Dings;

interface

type
  //Kleine Klasse
  TTest = class
    //weiteren Code brauchen wir hier nicht
  end;

var
  //globale Instanzvariable der Klasse
  Test: TTest;

implementation

//Direkt beim Einbinden Instanz von TTest erzeugen
initialization
  Test := TTest.Create;

//Ganz am Ende Instantz wieder freigeben
finalization
  Test.Free;

end.

[Ghostwalker]

Kleine Anmerkung noch:

Das ganze funktioniert natürlich auch in DLL's. Sobald also die DLL geladen wird, wird INITIALIZATION ausgeführt, beim freigeben der FINALIZATION teil.

[SebastianZ]

*zweite seite übersehen*:roll:

[hoika]

Hallo,
ich würde das nur benutzen, wenn es wirklich einen wichtigen Grund gibt.

Warum?
die Reihenfolge des Codes wird durch die uses-Reihenfolge,
also die Einbindungs-Reihenfolge der Units bestimmt.

Viel Spaß beim Debuggen von Abhängigkeiten zwischen Units.

(Unit A benutzt ein Unique-Pattern aus Unit B, wass zu früh freigegeben wird.)

[TRomano]

Ja, so etwas sollte man nur benutzen, wenn der Code, die Strukturen in dieser Unit komplett unabhängig vom Programm sind.
z.B. für System-Units wie CPU auslesen, OS-Versionen usw.

[himitsu]

Für "Komponenten" verwende ich stattdessen lieber Class-Constructor und Class-Destructor.

Grund: So kann der Compiler Linker die Klasse/Komponente wegoptimieren.
Über Initialization wird die Klasse/Komponente immer einkompilert/initialisiert, selbst wenn sie nicht verwendet wird. (sieht man zu gut an der RTL/VCL, wo man ständig allen Müll mitschleppt und sich jeder über große EXEn beschwert)

Leider ist bei Ressourcen der Linker zu doof.

[ConnorMcLeod]

gugl ist Dein Freund... erster Treffer bei der Suche nach "Delphi initialization" ;-)
https://www.delphi-treff.de/object-p...rogrammaufbau/

[Blup]

Ich verwende Initialization und Finalization, da es im Delphi2007 Class-Constructor und Class-Destructor noch nicht gibt.

Beispiel:

Delphi-Quellcode:

unit MyFactory;

interface

uses
  Contnrs;

type
  TMyObject = class abstract(TObject)
  end;

  TMyClass = class of TMyObject;

  TMyFactory = class(TObject)
  private
    class var
      FClassList: TClassList;
  protected
    class procedure Initialize;
    class procedure Finalize;
  public
    class procedure RegisterClass(AClass: TMyClass);
    class procedure UnRegisterClass(AClass: TMyClass);
  end;

implementation

class procedure TMyFactory.Initialize;
begin
  FClassList := TClassList.Create;
end;

class procedure TMyFactory.Finalize;
begin
  FClassList.Free;
end;

class procedure TMyFactory.RegisterClass(AClass: TMyClass);
begin
  FClassList.Add(AClass);
end;

class procedure TMyFactory.UnRegisterClass(AClass: TMyClass);
begin
  FClassList.Remove(AClass);
end;

initialization
  TMyFactory.Initialize;

finalization
  TMyFactory.Finalize;

end.