Konstruktoren in Delphi

[Dennis07]

Zitat von dataspider:

Den Parameter AOwner wegzulassen halte ich für keine gute Idee.
Du musst dich dann zwingend selbst um die Freigabe kümmern.
Nur wenn dein Form (TFehler) immer modal in einen try finally mit Freigabe aufgerufen wird, könnte man es akzeptieren.
Machen würde ich es dennoch nicht. Bei mir haben alle Konstruktoren eines TForms alse ersten Parameter AOwner...
Der Aufruf zum Erzeugen kann dann TFehler.Create(Nil, Color...) oder TFehler.Create(Application, Color...) etc. sein.

Frank

Oder im Destructor freigeben.
Oder im OnDestroy freigeben.
Das wären alles gültige Alternativen.

[Int3g3r]

Besten Dank für die Antworten.

Leider blicke ich immer noch nicht durch bei den Konstruktoren/Destruktoren.

Z.b

Delphi-Quellcode:

type
  TMail = Class
    smtp: TIdSMTP;
    sslIOHandler: TIdSSLIOHandlerSocketOpenSSL;

    private
    // Private
    public
    // Public
    constructor Create(param1, param2 : String);
    destructor Destroy;
  end;

  var
  Mail : TMail;

implementation

constructor TMail.Create(param1, param2 : String);
begin
  smtp := TIdSMTP.Create(nil);
  sslIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
end;

destructor TMail.Destroy;
begin
  if Assigned(smtp) then
      FreeAndNil(smtp);
  if Assigned(sslIOHandler) then
      FreeAndNil(sslIOHandler);
end;

4) Wann ist ein "Inherited" notwenig im Konstruktor/Dekonstruktor ? Sobald von einer Klasse geerbt wird, richtig ?
TMail = Class(TComponent) // Hier währe ein Inherited dann notwendig, richtig ? .

5) Wie bei meinem Beispiel zu sehen habe ich keinen "Standard-Konstruktor" erstellt.
Meine Klasse soll nur mit diesem Konstruktor mit Parameter instanziert werden können.
Bei C# ist ein Standardkonstruktor notwendig, ist das bei Delphi auch der Fall ?

6) Das Beispiel oben lässt sich kompillieren und instanzieren.
Leider verstehe ich aber nicht warum bei Mail.Free der Destruktor nicht abgehandelt wird.
Ich erzeuge Memory-Leaks, was mache ich falsch ?

Lösung zu 6) destructor Destroy; override;
Gruss Int3g3r

PS: Um Memory-Leaks zu Prüfen folgende Zeile beim Projekt->Quelltext einfügen
ReportMemoryLeaksOnShutdown := True;

[Dalai]

Zitat von Int3g3r:

4) Wann ist ein "Inherited" notwenig im Konstruktor/Dekonstruktor ? Sobald von einer Klasse geerbt wird, richtig ?

Setze einfach inmmer ein inherited; in den Konstruktor und Destruktor, bei ersterem (in aller Regel) am Anfang, im Destruktor ans Ende. Jede Klasse erbt von irgendeiner Basisklasse, und wenn es nur TObject ist, die zwar einen leeren Konstruktor hat, aber vielleicht ändert sich das mal.

Zitat:

Meine Klasse soll nur mit diesem Konstruktor mit Parameter instanziert werden können.

Das geht auch irgendwie, im Zweifel mit Prüfung bestimmter Variablen beim Aufruf anderer Methoden der Klasse. Will man den Konstruktor der Basisklasse verdecken und dem Compiler sagen, dass das so in Ordnung ist, kann man ihn mit overload; reintroduce; markieren. IIRC verhindert das aber nicht, den Konstruktor der Basisklasse zu nutzen.

Zitat:

Bei C# ist ein Standardkonstruktor notwendig, ist das bei Delphi auch der Fall ?

Jein. Es gibt immer den Konstruktor der Basisklasse, der immer dann verwendet wird, wenn in der abgeleiteten Klasse keiner definiert ist oder keiner mit passender Parametersignatur gefunden wird. Aber der Konstruktor der Basisklasse lässt nicht immer anwenden, z.B. bei abstrakten Klassen (TStrings).

Zitat:

6) Das Beispiel oben lässt sich kompillieren und instanzieren.
Leider verstehe ich aber nicht warum bei Mail.Free der Destruktor nicht abgehandelt wird.

Jeder Destruktor sollte/muss mit override; markiert werden, damit der der abgeleiteten Klasse gerufen wird, nicht der der Basisklasse. Tut man das nicht, gibt der Compiler eine Warnung, soweit ich weiß.

Grüße
Dalai

[himitsu]

Jupp, beim DESTRUCTOR immer das OVERRIDE.

Teilweise auch beim CONSTRUCTOR.
* siehe TComponent, wenn die Komponente zur DesignTime auf die Form soll, denn der DFM-Loader kennt nur "sein" Create.

* Es gibt zwar einen leeren Standard-Constructor in TObject, aber der muss nicht aufgerufen werden. (besser ist es aber, wenn er wird)
* * denn aktuell ist der eh leer
* * VOR dem Create (oder wie auch immer man das nennen mag) wird bei einem "CONSTRUCTOR" immer erstmal die Speicherinitialisierung durchgeführt, also vor dem Inhalt dies Create

INHERITED einach immer.
* wenn es nicht nötig ist, weil es nichts im Vorfahren gibt, dann ignoriert es der Compiler
* ansonsten ruft es die "gleichnamige" Methode mit den "gleichen" Parametern im Vorfahren auf (bzw. die Methode mit dem Namen den man angibt)

Am Einfachsten/Sinnvollsten ist es das INHERITED bei "erstellenden" Methoden (Create/Get/...) als Erstes auszuführen
und bei löschenden/freigebenden Methoden (Destroy/Delete/...) als Letztes. (Ausnahmen gibt es, aber meistens ist es so am Besten)

Im Delphi gibt es immer per Standard ein "leeres" Create.
* Wenn man nichts initialisieren will, dann braucht man also keinen Eigenen
* genauso beim DESCRUCTOR (hier gibt es im Delphi nur den "Destroy", welcher automatisch aufgerufen wird)
* * hat man nichts freizugeben, oder alles wird automatisch freigegeben (z.B. String, dyn. Array, Interface oder Variant), dann braucht man hier auch keinen eigenen DESTRUCTOR



Im Free/FreeAndNil ist bereits ein "if Assigned" eingebaut, also nochmal ist nicht nötig. (doppelt ist nicht falsch, nur unnötig)

Delphi-Quellcode:

type 
  TMail = class(TComponent)
  ...

constructor TMail.Create(param1, param2 : String);
begin
  inherited Create(nil);  // NIL: oder du baust den Owner auch in dein Create mit ein
  smtp := TIdSMTP.Create(Self);
  sslIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(Self);
end;

Hier wird automatisch Speicherverwaltet, daher ist für diese beiden Felder/Variablen kein Destructor nötig.

Das Inherite bei diesem Creaate(nil) ist nicht unbedingt nötig.
* mit inherited wird immer das Create(mit TComponent) im Vorfahren aufgerufen
* ohne inherited in deiner Klasse (sollte es dort so ein Create geben), ansonsten im Vorfahren

[Int3g3r]

Danke für die weiteren Antworten.

Zitat:

Setze einfach inmmer ein inherited; Jede Klasse erbt..

Also wenn ich TMail = Class schreibe erbt diese automatisch von TObject ?

Zitat:

Im Free/FreeAndNil ist bereits ein "if Assigned" eingebaut, also nochmal ist nicht nötig. (doppelt ist nicht falsch, nur unnötig)

Danke für den Hinweis das wusste ich nicht.

Nun habe ich noch eine weitere Frage.
Wie lässt sich der Owner in meinem Beispiel einbauen, bzw macht dies überhaupt Sinn ?

Delphi-Quellcode:

constructor TMail.Create(AOwner: TComponent, param1, param2 : String);
begin
  inherited Create;
  smtp := TIdSMTP.Create(nil);
  sslIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
end;

Ich kann bei inherited Create; keinen Owner angeben da meine Klasse von TObject erbt.
Das Create von TObject will keine Parameter.
Bzw was soll ich danach mit dem Owner anstellen wenn ich diesen im TMail.Create übergebe ?

Gruss Int3g3r.

[Dalai]

Zitat von Int3g3r:

Also wenn ich TMail = Class schreibe erbt diese automatisch von TObject ?

So ist es. TObject ist in der Klassenhierarchie ganz oben, sozusagen der Urvater aller Objekte.

TMail = Class ist dasselbe wie TMail = Class(TObject) .

Zitat:

Wie lässt sich der Owner in meinem Beispiel einbauen, bzw macht dies überhaupt Sinn ?

Delphi-Quellcode:

constructor TMail.Create(AOwner: TComponent, param1, param2 : String);
begin
  inherited Create;
  smtp := TIdSMTP.Create(nil);
  sslIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
end;

Ich kann bei inherited Create; keinen Owner angeben da meine Klasse von TObject erbt.
Das Create von TObject will keine Parameter.
Bzw was soll ich danach mit dem Owner anstellen wenn ich diesen im TMail.Create übergebe ?

Einen Owner gibt es erst bei TComponent. Entweder leitest du davon ab, oder du musst den Owner-Parameter weglassen. Kommt darauf an, was deine Klasse tun soll.

Grüße
Dalai