Wann is Class von TObject abgeleitet (FreeAndNil)

[norwegen60]

Hallo zusammen,

habe gerade festgestellt, dass meine Klasse nach FreeAndNil nicht sicher NIL ist. Ich habe dann in der Hilfe folgenden Hinweis gefunden:

Zitat:

Mit FreeAndNil stellen Sie sicher, dass eine Variable nach der Freigabe der Objektreferenz nil (Delphi) bzw. NULL (C++) ist. Im Parameter Obj wird eine Variable übergeben, die ein Objekt repräsentiert.


Warnung: Obj muss eine Instanz einer von TObject abgeleiteten Klasse sein.

Meine Frage ist nun, ob folgende Klasse als von TObject abgeleitet gilt:

Delphi-Quellcode:

type
TTest = class
private
public
  constructor Create;
  destructor Destroy; override;
end;

[stahli]

Hmm, eigentlich sollte eine Objektvariable nach FreeAndNil(Obj) immer nil sein.

Es wird letztlich

Delphi-Quellcode:

Obj.Free;

und

Delphi-Quellcode:

Obj := nil;

durchgeführt.

Der Hinweis könnte m.E. so interpretiert werden, dass Obj ein Objekt sein muss.

Ein Problem könnte sein, wenn im Destructor eine Expression auftritt.


Zeig vielleicht mal Dein Ursprüngliches Problem. Vielleicht lässt sich das ja aufklären.

[Uwe Raabe]

Zitat:

Zitat von norwegen60 (Beitrag 1460758)

Meine Frage ist nun, ob folgende Klasse als von TObject abgeleitet gilt:

Alle Klassen (class) sind von TObject abgeleitet, selbst wenn das nicht ausdrücklich da steht. Aber FreeAndNil hat einen typlosen Parameter, dem man so ziemlich alles übergeben kann. Intern wird das als Instanzvariable einer Klasse behandelt und die wird auf nil gesetzt.

Ich halte es auch für zielführender, du würdest dein reales Problem zeigen.

[jfheins]

Zitat:

Zitat von norwegen60 (Beitrag 1460758)

habe gerade festgestellt, dass meine Klasse nach FreeAndNil nicht sicher NIL ist.

Das ist jetzt vll. übermäßig penibel, aber deine Klasse kann nicht nil werden.

Du schreibst eine Klasse. Davon kannst du Instanzen erzeugen (mit .Create()) und du speicherst Verweise (/Referenzen) auf diese Instanzen in Variablen. Diese Verweise können nil werden.

Aber wenn ein Verweis nil wird, werden nicht alle Verweise auf die gleiche Instanz auch nil. Ich vermute, du machst sowas:

Delphi-Quellcode:

var a, b: TTest;
begin
a = TTest.Create();
b := a;
FreeAndNil(a);
// Ergebnis:
a = nil
b = 0x56a4bf00 // Verweist noch auf die Adresse, darf nicht mehr zugegriffen werden

[norwegen60]

Hoi, in so kurzer Zeit so viele Antworten. Corona machts möglich :-D

Bisher bin ich auch davon ausgegangen, dass bei keiner Angabe automatisch von TObject abgeleitet wird. Der explizite Hinweis in der Hilfe hat mich dann aber verunsichert. Wie könnte man denn dann eine Klasse erstellen, die nicht von TObject abgeleitet ist?

Hier mein vereinfachtes Konstrukt

Delphi-Quellcode:

unit uTestClass;

interface

type
  TTestClass= class
  private
  public
    constructor Create;
    destructor Destroy; override;
  end;

var
  TestClass: TTestClass;

implementation
...
end.

unit Test;
interface

type
  TTestForm = class(TForm);
   published
    procedure FormCreate(Sender: TObject);
 
  private
  public
    constructor Create;
    destructor Destroy; override;

    procedure TuWas;
  end;

var
  TestClass: TTestClass;

implementation

procedure TTestForm.TuWas;
// Wird bei bestimmtem ProzessStand von Timer immer wieder aufgerufen
begin
  ...

  if not TestForm.TestClassReady then   // Wenn noch nicht gestartet oder noch nicht fertig
  begin 
    if TestClass = nil then
      TestClass := TTestClass.Create;

    if not TestClass.TuWasAnderesReady then
    begin
      TestClass.TuWasAnderes;
      Exit;
    end 
    else
    begin
      TestForm.TestClassReady := true;
      FreeAndNil(TestClass);
    end;
  end;
  ...
end.

Ich hoffe das stellt das Konstrukt verständlich da

Wenn ich nun TTestForm beende und für einen zweiten Lauf TTestForm.Create neu erzeuge ist beim zweiten Durchlauf TestClass.TuWasAnderesReady = True
Das wird bei TTestClass.Create auf false gesetzt
Beim zweiten Aufruf wird TTestClass.Create aber gar nbicht aufgerufen weil nicht Nil

Ich prüfe aber noch mal, ob der Fehler sich anderst einschleicht

[DeddyH]

Zitat:

Wie könnte man denn dann eine Klasse erstellen, die nicht von TObject abgeleitet ist?

Überhaupt nicht. TObject ist die Mutter aller Klassen, d.h. jede andere Klasse ist letzten Endes von ihr abgeleitet, egal wieviele Hierarchiestufen dazwischenliegen.

[norwegen60]

Eben. Und damit ist der Hinweis sinnfrei.

Ich schau woher das Problem kommt. Wollte das nur grundsätzlich wissen.

Aber eine Frage hätte ich doch noch zu dem Thema.

Stimmt es, dass alleine mit der Zuweisung

Delphi-Quellcode:

TestClass := nil;

auch der Speicher frei gegeben wird?

[DeddyH]

Nein. Das ist nur dann der Fall, wenn die Klasse ein Interface mit Referenzzählung implementiert (z.B. TInterfacedObject), über eben dieses Interface angesprochen wird und die letzte Referenz auf nil gesetzt wird. Ansonsten baust Du Dir mit der nil-Zuweisung ein Speicherleck, sofern keine andere Referenz auf die Instanz mehr existiert.

[DenkDirNix]

Zitat:

Wie könnte man denn dann eine Klasse erstellen, die nicht von TObject abgeleitet ist?

Das geht laut Doku mit dem Schlüsselwort "object", siehe unter "Object Types" in

http://docwiki.embarcadero.com/RADSt...jects_(Delphi)

[dummzeuch]

Zitat:

Zitat von DenkDirNix (Beitrag 1460768)

Zitat:

Wie könnte man denn dann eine Klasse erstellen, die nicht von TObject abgeleitet ist?

Das geht laut Doku mit dem Schlüsselwort "object", siehe unter "Object Types" in

http://docwiki.embarcadero.com/RADSt...jects_(Delphi)

Wow, die guten alten Turbo-Pascal Objekte sind inzwischen offiziell dokumentiert? Ich dachte, die hätten schon seit 20 Jahren den Status "der Compiler unterstützt sie noch, aber wenn Du ein Problem hast, hast Du halt Pech gehabt". Manchmal wären die echt noch praktisch, aber ich traue mich nicht, sie einzusetzen.

[norwegen60]

Alles klar und vielen Dank.
Meine Fragen sind ausreichend beantwortet.

[DeddyH]

Die haben bei mir den Weg von GoTo und With genommen, d.h. in meinem Wortschatz existieren sie nicht :mrgreen:

[norwegen60]

GoTo ist klar. Aber was spricht gegen With?
Ausser dass man dann im Code nicht gleich sieht, wo das Property/Object her kommt.
Gibt es noch andere Gründe?

PS: Mein Problem ist auch gefunden. Er ist nie in die FreeAndNil-Zeile gekommen :oops:

[himitsu]

In etwas neueren Delphis, wenn für Nextgen mit ARC kompiliert, dort gibt es Weak-Referenzen, die automatisch auf NIL gesetzt werden, wenn das Objekt freigegeben wird.

Erstmal werden beim ARC die Referenzen gezählt und das Objekt die Instanz des Objektes wird erst freigegeben, wenn alle Variablen weg sind.
Free, FreeAndNil und Destroy machen dort absolut garnichts (ja, das ist ein extrem blödes Verhalten und der Mist mit dem DisposeOf ist schwachsinn)

Jedenfalls gibt es dort das Attribut

Delphi-Quellcode:

[Weak]

, was auch extrem krank ist, denn das Attribut kann man auch bei Nicht-ARC angeben, aber es wird dort ohne Fehlermeldung einfach still und heimlich ignoriert. (ja, ich würde den Erfinder gern mal grün nd blau hauen, aber so richtig)

Delphi-Quellcode:

{$IFNDEF AUTOREFCOUNT} {MESSAGE Fatal 'du kommst hier net rein'} {$ENDIF}

var
  x, y: TObjekt;
  [Weak] z: TObjekt;

x := TObject.Create;
y := x;  // diese Referenz wird gezählt
z := x;  // diese Weak-Referenz wird nicht gezählt und automatisch NIL
if z = nil then ;  // nee

x := nil;  // das automatische x.Free, aber da Y noch existiert
y := nil;  // jetzt wirklich das automatische Free und Z wird genilt
if z = nil then ;  // jupp, ist auch weg

Im Prinzip bekommt die Objektinstanz hier eine Adress-Liste wo alle Weak-Referenzen liegen und beim Destroy werden sie auf NIL gesetzt.



Bei ARC muß man extrem aufpassen keine Kreisreferenzen zu bekommen

Delphi-Quellcode:

type 
  TChild = class;

  TOwner = class
    FChild: TChild;  // oder gat viele Childs
  end;

  TChild = class
    [Weak] FTOwner: TOwner;
  end;

Ohne WEAK würden im ARC sich die beiden Instanzen gegenseitig halten, selbst wenn es extren keine Referenzen/Variablen mehr gibt.
Im Prinzip arbeiten alle Objekte dort wie Interfaces.

[Jasocul]

Zitat:

Zitat von norwegen60 (Beitrag 1460772)

Aber was spricht gegen With?

1. Versuche mal, solche Stellen zu debuggen.
2. Manchmal soll es auch vorkommen, dass der Compiler da was verwechselt.

Da ich with aus dem ersten Grunde schon nicht verwende, habe ich keine praktischen Erfahrungen mit dem zweiten Phänomen.

[Uwe Raabe]

Zitat:

Zitat von Jasocul (Beitrag 1460783)

2. Manchmal soll es auch vorkommen, dass der Compiler da was verwechselt.

Das wird dann wohl eher der Entwickler sein.

[himitsu]

Zitat:

Zitat von Jasocul (Beitrag 1460783)

2. Manchmal soll es auch vorkommen, dass der Compiler da was verwechselt.

Jo, der Entwickler, bzw. das arme Schwein, was später das mal lesen soll.

Zitat:

Zitat von Jasocul (Beitrag 1460783)

Zitat:

Zitat von norwegen60 (Beitrag 1460772)

Aber was spricht gegen With?

1. Versuche mal, solche Stellen zu debuggen.

Erstmal das und dann das beste Beispiel

Delphi-Quellcode:

var R: TRect;

with R do
  {Self.}Width := {R.}Right - {R.}Left;  // was der Entwickler sich dachte und wie es früher war
  
{with R do}
  R.Width := R.Right - R.Left;  // Was Delphi jetzt macht, seitem TRect mit einem Helper verbessert wurde
  
{Self.}Width := R.Width;  // und was man jetzt auch machen kann

[dummzeuch]

Zitat:

Zitat von DeddyH (Beitrag 1460771)

Die haben bei mir den Weg von GoTo und With genommen, d.h. in meinem Wortschatz existieren sie nicht :mrgreen:

With ist böse, klar, aber was spricht gegen Goto?

SCNR ;-)

[uligerhardt]

Zitat:

Zitat von dummzeuch (Beitrag 1460769)

Wow, die guten alten Turbo-Pascal Objekte sind inzwischen offiziell dokumentiert? Ich dachte, die hätten schon seit 20 Jahren den Status "der Compiler unterstützt sie noch, aber wenn Du ein Problem hast, hast Du halt Pech gehabt". Manchmal wären die echt noch praktisch, aber ich traue mich nicht, sie einzusetzen.

So aus Neugier: Wofür würdest du sie denn nutzen? Nach meiner Erfahrung kann man alles, was man mit old-style-objects machen kann, auch mit Records mit Methoden erledigen, oder class-Typen sind eh die bessere Wahl. Ausnahmen wären vielleicht polymorphe Objekte auf dem Stack oder so?

[himitsu]

Nichts?
IF ist ein oder zwei versteckte GOTO, CASE ist mehrere GOTO, WHILE und REPEAT sind GOTO, ... (bzw. alle sind JUMPs)

Und WITH ist auch nur eine unsichtbare temporäre Variable, der man leider nicht ansieht, wo die nun alles dranhängt.

[dummzeuch]

Zitat:

Zitat von uligerhardt (Beitrag 1460810)

Zitat:

Zitat von dummzeuch (Beitrag 1460769)

Wow, die guten alten Turbo-Pascal Objekte sind inzwischen offiziell dokumentiert? Ich dachte, die hätten schon seit 20 Jahren den Status "der Compiler unterstützt sie noch, aber wenn Du ein Problem hast, hast Du halt Pech gehabt". Manchmal wären die echt noch praktisch, aber ich traue mich nicht, sie einzusetzen.

So aus Neugier: Wofür würdest du sie denn nutzen? Nach meiner Erfahrung kann man alles, was man mit old-style-objects machen kann, auch mit Records mit Methoden erledigen, oder class-Typen sind eh die bessere Wahl. Ausnahmen wären vielleicht polymorphe Objekte auf dem Stack oder so?

Genau das. Und Array of object.

[uligerhardt]

Zitat:

Zitat von dummzeuch (Beitrag 1460813)

Genau das. Und Array of object.

Mein Kollege hat dummerweise an zentraler Stelle eine Klassenhierarchie mit objects aufgebaut. Ich kann nur sagen - das "deprecated" steht nicht ohne Grund in der Doku. Vtables von Objekten auf dem Stack werden nicht zuverlässig initialisiert und lauter so Kleinigkeiten.

[dummzeuch]

Zitat:

Zitat von uligerhardt (Beitrag 1460814)

Zitat:

Zitat von dummzeuch (Beitrag 1460813)

Genau das. Und Array of object.

Mein Kollege hat dummerweise an zentraler Stelle eine Klassenhierarchie mit objects aufgebaut. Ich kann nur sagen - das "deprecated" steht nicht ohne Grund in der Doku. Vtables von Objekten auf dem Stack werden nicht zuverlässig initialisiert und lauter so Kleinigkeiten.

Genau deshalb benutze ich sie nicht mehr. Sie wären halt praktisch, wenn sie denn noch sauber implementiert wären. Seit es die erweiterten Records gibt, tut es nicht mehr ganz so weh, auf Objekte zu verzichten.