AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Interessantes Destruktor Problem

Ein Thema von sx2008 · begonnen am 7. Jan 2011 · letzter Beitrag vom 7. Jan 2011
Antwort Antwort
Benutzerbild von Deep-Sea
Deep-Sea

Registriert seit: 17. Jan 2007
907 Beiträge
 
Delphi XE2 Professional
 
#1

AW: Interessantes Destruktor Problem

  Alt 7. Jan 2011, 09:01
Delphi-Quellcode:
constructor TGrundklasse.Create(AStream: TStream);
begin
  inherited Create;
end;

destructor TGrundklasse.Destroy;
begin
  inherited;
end;

constructor TAbgeleiteteKlasse.Create;
begin
  FStream := TMemoryStream.Create;
  inherited Create(FStream);
end;

destructor TAbgeleiteteKlasse.Destroy;
begin
  inherited; // Könnte ja auf den übergebenen Stream noch zugreifen.
  FStream.Free;
end;
Destroy von TGrundklasse:
Code:
Unit1.pas.47: inherited;
0046491F 8BD3             mov edx,ebx
00464921 80E2FC          and dl,$fc
00464924 8BC6             mov eax,esi
00464926 E8B9F1F9FF      call TObject.Destroy
Unit1.pas.48: end;
0046492B 84DB            test bl,bl
0046492D 7E07             jle $00464936 // Springt um ClassDestroy herum.
0046492F 8BC6             mov eax,esi
00464931 E846F6F9FF      call @ClassDestroy // Ruft FreeInstance auf.
00464936 5E              pop esi
00464937 5B              pop ebx
00464938 C3               ret
00464939 8D4000           lea eax,[eax+$00]
Richtig, ClassDestroy, was FreeInstance aufrufen wird, steht hier drin. ABER: Durch den bedingten Sprungbefehl jle wird es hier nicht aufgerufen!

Destroy von TAbgeleiteteKlasse:
Code:
Unit1.pas.58: inherited;
00464993 8BD3             mov edx,ebx
00464995 80E2FC          and dl,$fc
00464998 8BC6             mov eax,esi
0046499A E875FFFFFF      call TGrundklasse.Destroy
Unit1.pas.59: FStream.Free;
0046499F 8B4604           mov eax,[esi+$04]
004649A2 E84DF1F9FF      call TObject.Free
Unit1.pas.60: end;
004649A7 84DB            test bl,bl
004649A9 7E07             jle $004649b2 // Springt nicht.
004649AB 8BC6             mov eax,esi
004649AD E8CAF5F9FF      call @ClassDestroy // Ruft FreeInstance auf.
004649B2 5E              pop esi
004649B3 5B              pop ebx
004649B4 C3               ret
004649B5 8D4000           lea eax,[eax+$00]

@Neutral General:
Zwingt dich auch keiner zu, wenn du schnell den Überblick verlierst. Aber falsch ist es immer noch nicht.


Danke Uwe, endlich mal jemand der auf meiner Seite steht
Chris
Die Erfahrung ist ein strenger Schulmeister: Sie prüft uns, bevor sie uns lehrt.
  Mit Zitat antworten Zitat
Benutzerbild von Neutral General
Neutral General

Registriert seit: 16. Jan 2004
Ort: Bendorf
5.219 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#2

AW: Interessantes Destruktor Problem

  Alt 7. Jan 2011, 09:07
Zitat von DeepSea:
@Neutral General:
Zwingt dich auch keiner zu, wenn du schnell den Überblick verlierst. Aber falsch ist es immer noch nicht.
Ne "falsch" ist es nicht. Aber man muss aufpassen was man macht und das kann eben schnell in die Hose gehen. Wenn man das inherited als letztes aufruft, dann ist man auf der sicheren Seite und kann im Destructor vor dem inherited machen was man will ohne befürchten zu müssen, dass einem alles um die Ohren fliegt.

Abgesehen davon ist es deutlich sauberer das inherited in Destructoren immer (!) als letztes aufzurufen. So wird das Objekt ganz geordnet "von oben nach unten" abgeräumt. Wenn jeder sein inherited irgendwo an den Anfang oder in die Mitte des Destructors setzt ist es als würde man aus nem Turm irgendwo in der Mitte ein Stein rausziehen... ( Jenga)
Michael
"Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination,
but because their imagination reveals worlds that others cannot see."
  Mit Zitat antworten Zitat
Benutzerbild von Bummi
Bummi

Registriert seit: 15. Jun 2010
Ort: Augsburg Bayern Süddeutschland
3.470 Beiträge
 
Delphi XE3 Enterprise
 
#3

AW: Interessantes Destruktor Problem

  Alt 7. Jan 2011, 09:14
Delphi-Quellcode:
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type

  TMyObject = class
  Private
    FMyTest:TStringList;
    function GetInfo: String;
  public
    destructor Destroy; override;
    Constructor Create;virtual;
    procedure FreeInstance; override;
    Property Info:String Read GetInfo;
  end;
  TMyObject2 = class(TMyObject)
  public
    destructor Destroy; override;
    Constructor Create;override;
    procedure FreeInstance; override;
 end;
  TForm1 = class(TForm)
    ADODataSet1: TADODataSet;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  With TMyObject2.Create do Free;

end;
{ TMyObject }

constructor TMyObject.Create;
begin
  inherited;
  FMyTest:=TStringList.Create;
  FMyTest.Add('Text');
end;

destructor TMyObject.Destroy;
begin
  FMyTest.Free;
  inherited;
end;

procedure TMyObject.FreeInstance;
begin
  inherited;

end;

function TMyObject.GetInfo: String;
begin
   Result := FMyTest.Text;
end;

{ TMyObject2 }

constructor TMyObject2.Create;
begin
  inherited;

end;

destructor TMyObject2.Destroy;
begin
  Showmessage('Vor inherited:' +Info);
  inherited;
  Showmessage('Nach inherited:' +Info);
end;

procedure TMyObject2.FreeInstance;
begin
  inherited;

end;

end.
Thomas Wassermann H₂♂
Das Problem steckt meistens zwischen den Ohren
DRY DRY KISS
H₂ (wenn bei meinen Snipplets nichts anderes angegeben ist Lizenz: WTFPL)
  Mit Zitat antworten Zitat
Benutzerbild von Deep-Sea
Deep-Sea

Registriert seit: 17. Jan 2007
907 Beiträge
 
Delphi XE2 Professional
 
#4

AW: Interessantes Destruktor Problem

  Alt 7. Jan 2011, 09:18
@Bummi:
Und was soll uns der Code zeigen?

@mleyen:
Darum sollte man auch LERNEN wie etwas funktioniert, anstatt einfach irgendeine Aussage von wegen "Es muss so sein, frag nicht warum, es ist halt so!" zu glauben
Und wenn man schon mit so einem Anfänger im Team arbeitet, gibt es ja noch die guten alten Kommentare, um zu erklären, warum hier etwas nach inherited steht obwohl das ja sooo böse ist.
Und einen Grund gibt es auch, dass zu tun: Wenn man z.B. eine von Uwe Raabe genannte Klasse ableiten will, kann es u.U. unerlässlich sein.
Chris
Die Erfahrung ist ein strenger Schulmeister: Sie prüft uns, bevor sie uns lehrt.

Geändert von Deep-Sea ( 7. Jan 2011 um 09:21 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:16 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz