Sinn & Funktion Initialisierungs-/Finalisierungsteil

[hannes2011]

Hallo zusammen,

in einem Informatikvortrag soll ich in einen Programmbeispiel auch den Initialisierungs- und den Finalisierungsteil einer Unit nutzen.
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.
Schön und gut - wie sieht das nun aber programmiertechnisch aus - hat da jemand ein Beispiel für mich?
Muss ich nun den Initialisierungsteil noch mit begin & end bestücken oder nicht? Da fängts ja schon an....
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 -.-.

Anbei mal ne ganz simple Unit - alles super, aber wie packe ich nun was da bei Initialization und Finalization rein?
Würde mich freuen, wenn mir jemand da kurz weiterhelfen könnte - vielen Dank für die Bemühungen im Voraus!!!

LG

- Hannes


-----

Delphi-Quellcode:

unit Unit1;

interface

procedure werte_einlesen(var k,w:real);
procedure ausgabe(x,y:real);

implementation

procedure werte_einlesen(var k,w:real);
begin
writeln('Eingabe k');
readln(k);
writeln('Eingabe w');
readln(w);
end;

procedure ausgabe(x,y:real);

var i:real;

begin
i:=x*y;
writeln('Ausgabe:',i:3:2);
end;

initialization

finalization

end.

[edit=SirThornberry]Delphi-Tags gesetzt - nächstes mal bitte selbst machen - Mfg, SirThornberry[/edit]

[Alaitoc]

Also ein gutes Beispiel wäre z.b. ein Singleton, d.h. ein Objekt das halt irgendwann einmal erstellt wird und dann theorethisch überall aufgerufen werden kann und immer das gleiche eine Objekt ist. Z.b. ein Manager an dem Objekte dran hängen, die über Änderungen informiert werden.

Im Finalization-Teil könnte man dort z.b. damit man sicher ist das das Objekt freigegeben wird, das Objekt am Ende des Programms wieder freigeben und die Objekte die an ihm hängen vorher abmelden.

Zum Initialization-Teil fällt mir grade nichts ein :gruebel:

MfG Alaitoc

[omata]

Für den Initialization-Teil ist ein einfach es Beispiel das nötige randomize beim Verwenden von random.

Oder eben ein Objekt z.B. TList, das in der Unit benötigt wird, das kann man dann beim Start anlegen und beim Beenden wieder zerstören...

[hannes2011]

Ahhhhhhso - das hilft mir schon mal weiter, vielen, vielen Dank!
Das bedeutet, dass man in der simplen Konsolenanwendung zum Beispiel das realdln, was man ja benötigt, damit man die Ergebnisse noch sieht, einfach in den Finalisierungs-Teil packen könnte...

Jedenfalls hat es ansätzlich klick gemacht - vielen Dank für die schnelle Hilfe an euch & liebe Grüße
- Hannes :-)

[p80286]

Das ist die Spielwiese für böse Buben die die Finger nicht von globalen Variablen lassen können

Delphi-Quellcode:

unit u1

var
  mystringlist : tstringlist;

.....

initialization
  mystringlist:=tstringlist.create;
finalization
  mystringlist.free;
end;

Gruß
K-H

Edit:
Das Readln gehört mehr zum eigentlichenProgrammablauf.
da wird nur Aufgebaut und wieder aufgeräumt

[Sir Rufo]

Zitat:

Zitat von hannes2011

Ahhhhhhso - das hilft mir schon mal weiter, vielen, vielen Dank!
Das bedeutet, dass man in der simplen Konsolenanwendung zum Beispiel das realdln, was man ja benötigt, damit man die Ergebnisse noch sieht, einfach in den Finalisierungs-Teil packen könnte...

Jedenfalls hat es ansätzlich klick gemacht - vielen Dank für die schnelle Hilfe an euch & liebe Grüße
- Hannes :-)

oh, gott ... bloß nicht!

In einer simplen Konsolenanwendung kannst du das Readln als letzten Befehl schreiben und gut.
Dieses Beispiel wird dir jeder vernünftige Informatiker zerpflücken.
Und jeden Laien wirst du damit auf die falsche Fährte bringen.

[guinnes]

Auch wenn initialization und Finalisation in der Unit leer sind, wird trotzdem per Compiler-Magic was gemacht, z.B. Strings finalisiert

[DeddyH]

Hat eigentlich schon jemand erwähnt, dass initialization- und finalization-Abschnitte nur einmalig im gesamten Programm abgearbeitet werden, egal wie oft die Unit eingebunden wird?

[Sir Rufo]

btw.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

// Hier nix mit initialization oder finalization

begin
  try
    { TODO -oEntwickler -cKonsole Main : Hier Code einfügen }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

[hannes2011]

Zitat:

Zitat von Sir Rufo

oh, gott ... bloß nicht!

In einer simplen Konsolenanwendung kannst du das Readln als letzten Befehl schreiben und gut.
Dieses Beispiel wird dir jeder vernünftige Informatiker zerpflücken.
Und jeden Laien wirst du damit auf die falsche Fährte bringen.

Weia...da gäbe es dann also schön Ärger...ok, falscher Gedankengang.
Ok, das mit der Stringliste klingt ja relativ sinnvoll - bei Programmstart freigeben/erstellen und bei Programmende den Speicherplatz/die Liste wieder freigeben.

Guuuut...großes Dankeschön an euch!

[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:

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:

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:

Zitat von Sir Rufo

Delphi-Quellcode:

// 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:

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.