destructor in delphi.net?

[Aenogym]

hi ihr,

ich darf mich jetzt in delphi.net einarbeiten und stehe schon vor einem problem:
gibt's keine destructors mehr?

ich habe folgenden code versucht:

Delphi-Quellcode:

type
  TIceClientConnection = class
  private
    fClient: TcpClient;
    function GetConnected: boolean;
  public
    property Connected: boolean read GetConnected;
    constructor Create(Host: string; Port: integer); overload;
    destructor Destroy;
  end;

an der zeile mit dem destructor gibt's allerdings die compiler-meldung "Nicht unterstütztes Sprachfeature". In der Hilfe steht nichts davon, dass es destructors unter .net nicht gibt.

deshalb nun meine frage: wie realisiere ich einen destructor?

danke euch,
Aenogym

[Dax]

Gar nicht Unter .net werden Objekte automatisch gekillt, wenn sie aus dem Scope rennen, inkl Unterobjekte, die dann ja noch weniger im Scope sind.

[Aenogym]

Zitat von Dax:

Gar nicht Unter .net werden Objekte automatisch gekillt, wenn sie aus dem Scope rennen, inkl Unterobjekte, die dann ja noch weniger im Scope sind.

danke dir. jetzt, wo du es sagst, fällt mir ein, dass ich das vor kurzem bei visual c# express gelesen hab

aenogym

[Robert_G]

Es gibt finalizer, die werden ausgeführt, wenn das Object zerstört wird.
Aaaber, wenn man sie nicht braucht sollte man sich nicht die Finger daran verbrenne, da dadurch GC sweeps _wesentlich_ mehr Performance schlucken.
Ich dachte Borland würde den Destructor auf Dispose ummünzen.
Ich weiß nicht, ob du mit D.Net Finalizer anlegen kannst.

[jbg]

[quote="Aenogym"]destructor Destroy;[/delphi]
Da fehlt wohl ein override;

Zitat:

an der zeile mit dem destructor gibt's allerdings die compiler-meldung "Nicht unterstütztes Sprachfeature". In der Hilfe steht nichts davon, dass es destructors unter .net nicht gibt.

Unter Delphi.NET wird das Schlüsselwort destructor auf die Methode Dispose umgemünzt und das Interface IDisposable der Klasse hinzugefügt.
Will man den .NET Destruktor (Finalize) haben, dann muss man die Methode Finalize überschreiben. Aber wie Robert schon schrieb, zieht das an der Performance-Bremse. Deswegen hat Microsoft auch das Konzept des IDisposable Interfaces eingeführt, damit man eine deterministischen Freigabe von Ressourcen hat.

Was aber unglücklich an .NET ist, ist dass man nicht nicht weiß, wann ein Objekt die IDisposable Schnittstelle unterstützt und wann nicht. Es heißt also bei nicht regelmäßig genutzen Klassen immer Code-Insight bzw. das .NET SDK konsultieren. Nutzt man bei Delphi.NET das TObject.Free, wo kümmert sich .Free darum, dass bei Objekten, die IDisposable unterstützen, diese auch aufgerufen wird und bei allen anderen Objekte nicht gemacht wird.

.NET Destruktoren werden übrigens asynchron zum Code ausgeführt. Sie laufen also in einem anderen Thread. Und dass kann dann zu wunderschönen Problemen führen, wenn man das nicht weiß und die Synchronisation vergisst (sofern man externe Ressourcen nutzt).

[Robert_G]

Zitat:

Was aber unglücklich an .NET ist, ist dass man nicht nicht weiß, wann ein Objekt die IDisposable Schnittstelle unterstützt und wann nicht.

Ich verwende Doku tags auf Dispose bzw. Versuche es gar nicht soweit kommen zu lassen...
Bei portierten D.Net Assemblies kann ich mir gut vorstellen, dass 90% IDIspoable sind, ohne es zu brauchen.

Es ist auch immer hilfreich, den Reflector nebenbei auf zu haben.

Zitat:

.NET Destruktoren werden übrigens asynchron zum Code ausgeführt. Sie laufen also in einem anderen Thread. Und dass kann dann zu wunderschönen Problemen führen, wenn man das nicht weiß und die Synchronisation vergisst (sofern man externe Ressourcen nutzt).

Das ist ja die krasse Bremse, dass sich die GC eiinen Wolf locken muss.

[malo]

Mich würde auch mal interessieren, welchen Vorteil es eigentlich hat, dass die Destruktoren in .NET einen eigenen Thread haben

[Speedmaster]

Also ich vermute mal das sich die Methode das die Objekte per Thread freigegeben werden bei größeren Objekten verhindert das die Anwendung zu lange "nicht verfügbar" ist.
Die Idee ist durchaus nicht schlecht. Ob es sich bei kleineren Objekten auszahlt ist allerdings Fraglich.

[Robert_G]

Die ganze GC läuft in einem eigenen Thread, das ist ja das coole daran. Ein sweep oder die Verwaltung wird deine App nicht einfrieren lassen.