Destructor notwendig bei class?

[Alex_ITA01]

Hallo zusammen,
folgendes Beispiel:

Delphi-Quellcode:

  TMyData = record
    a   : Integer;
    b   : AnsiString;
    c   : TDateTime;
  end;

  TMyObject = class
    aData       : TMyData;
    constructor Create (NewData: TMyData);
    function GetString: AnsiString;
  end;

Delphi-Quellcode:

procedure DoAnything;
var
  NewObj : TMyObject;
  aNewData : TMyData;
begin
  aNewData.a := 99;
  aNewData.b := 'Hallo';
  aNewData.c := Now;
  NewObject := TMyObject.Create (aNewData);

  //das NewObject in eine TStringList packen und irgendwas damit machen...
end;

procedure AllesFreigeben;
var
  aObj : TMyObject;
begin
  //Schleife über die TStringList zum Freigeben der Objekte...
  for i := 0 to ....
  begin
    aObj := Liste.Objects[i] as TMyObject;
    if Assigned(aObj) then
    begin
      FreeAndNil(aObj);
    end;
  end;
end;

Nur ein Beispiel...
Muss ich ein destructor für meine Klasse machen und die Strings da irgendwie freigeben oder ist das alles gut so?

Gruß

[Bummi]

Die Liste muss ja auch irgendwo erzeigt und freigegeben werden ...
zusätzlich würde ich AllesFreigeben im Destruktor zusätzlich aufrufen, allerdings muss die Prozedur dann so umgebaut werden Liste.Objects[i] nach der Freigabe eines Objekts nil ist.

[Iwo Asnet]

Du musst keinen Destruktor angeben, wenn es nichts destruktives zu tun gibt.
@Bummi: 'AllesFreigeben' sowie 'Liste' sind keine Bestandteile der Klasse.

[Progman]

Für Objects würde ich aber keine TStringList verwenden, sondern eine TList.
AllesFreigeben würde ich nie in einer for-Schleife machen sondern:

Delphi-Quellcode:

procedure AllesFreigeben;
var
  aObj : TMyObject;
begin
  //Schleife über die TStringList zum Freigeben der Objekte...
  while Liste.Count > 0 do
  begin
    aObj := Liste.Objects[0] as TMyObject;
    if Assigned(aObj) then FreeAndNil(aObj);
    Liste.Delete(0); //auch Listeneintrag löschen
  end;
  //evtl. auch gleich Liste freigeben
  Liste.Free;
end;

Ein destructor ist nur dann zweckmäßig, wenn im Create des Objects etwas erzeugt wird, dass vor dem Freigeben des Objechts ebenfalls freigegeben werden muss.

[Bummi]

@Iwo Asnet

Danke, ich habe gepennt ...

[Iwo Asnet]

Zitat:

Zitat von Progman (Beitrag 1170638)

AllesFreigeben würde ich nie in einer for-Schleife machen sondern: (while schleife)

Wieso das denn? Das ist doch vollkommen überflüssig.

Delphi-Quellcode:

For i:=0 to List.Count - 1 do
  List[i].Free;

List.Free;

Reicht vollkommen, ist sicher, kurz, verständlich und sauber. Was will man mehr?

Ich würde für Objekte übrigens eine TObjectList geben und dann per

Delphi-Quellcode:

MyObjectList := TObjectList.Create(True);
...
MyObjectList.Free;

alles wieder freigeben. Das ist dann noch sicherer, kürzer, verständlicher und sauberer, sozusagen porentief :stupid:

[spaxxn]

@Iwo: Das funktioniert, gebe ich Dir recht, aber ist mehr als unsauberer Stil.

[TiGü]

Zitat:

Zitat von spaxxn (Beitrag 1170645)

@Iwo: Das funktioniert, gebe ich Dir recht, aber ist mehr als unsauberer Stil.

Was ist die Begründung dafür?

[Iwo Asnet]

Zitat:

Zitat von spaxxn (Beitrag 1170645)

@Iwo: Das funktioniert, gebe ich Dir recht, aber ist mehr als unsauberer Stil.

Also das würde nun auch interessieren, was daran unsauber sein soll. Bisher war ich der Auffassung, das einfach, sicher, klar, minimalistisch und elegant 'sauberer Stil' ist. Aber bitte, liefere uns eine Begründung und ich lerne immer wieder gerne dazu.

Zum Beispiel der 'sauberen Lösung':
1. Wieso wird das Listenelement in eine lokale Variable?

2. Die Zeile

Delphi-Quellcode:

 If Assigned (aObj) then FreeAndNil(aObj)

ist redundant, dann die Prüfung auf NIL wird eh von FreeAndNil übernommen.

3. FreeAndnil ist überflüssig. Wozu eine lokale Kopie des Objektes mit 'FreeAndNil' freigeben, wenn sie im nächsten Schleifendurchlauf überschrieben wird?

4. Dann verstehe ich nicht, wieso immer das erste Element entfernt wird. Wenn ich mir schon so einen abbreche, dann doch wenigstens das letzte Element. Dann spare ich mir dann diese eine Zeile

Delphi-Quellcode:

Liste.Delete(0)

. Somit wird eine einfache Aufräumaktion zu einem Flaschenhals, denn die Aktion ist vom Aufwand O(n*n), wo doch O(n) reichen würde.

Also: So ziemlich jede Zeile ist aufgebläht und überflüssig.

Für mich ist das Schulungsmaterial, wie man etwas sehr Banales kompliziert umsetzen kann. Wesentlich komplizierter als in diesem Beispiel kann ich mir jedenfalls nicht vorstellen, eine Liste von Objekten inklusive Inhalt freizugeben.

So, und jetzt sag mir nochmal, wo der Stil bei meiner Variante 'unsauber' bzw. der andere Code so 'sauber' ist.

[spaxxn]

1. Ging es bei der Aussage nur um den Stil
2. Gibst du zwar jedes Objekt frei, dies allerdings indexbasiert. Löscht aber nicht im gleichen Zug den Index dazu aus der Liste. Dadurch sorgst du bewusst dafür, dass die Liste nicht mehr synchron, mit Elementen und darin enthalten Objekten, ist
3. Das Clear, das im Destruktor von TList aufgerufen wird, ist kein Freifahrtsschein dafür, sich nicht vernünftig um die Elemente der Liste, gerade beim Freigeben, zu kümmern
4. Wird das schon in der Vorlesung "Grundlagen der Informatik" gelehrt und ist in der Informatik allgemeingültig

Edit: Bei der TObjectList mit OwnsObjects = true, sieht die Sache im Übrigen schon anders aus, allerdings wird dort die virtuelle Methode Notify überschrieben und sorgt dort dann für jedes einzelne Element der Liste auch für die Freigabe des Objektes.

[Blup]

Zitat:

1. Ging es bei der Aussage nur um den Stil

Stil ist subjektiv, ich finde den Stil von Iwo Asnet besser.

Zitat:

2. Gibst du zwar jedes Objekt frei, dies allerdings indexbasiert. Löscht aber nicht im gleichen Zug den Index dazu aus der Liste. Dadurch sorgst du bewusst dafür, dass die Liste nicht mehr synchron, mit Elementen und darin enthalten Objekten, ist

Das ist auch nicht notwendig und solche Zustände sind im Programmablauf nur schwer zu vermeiden.
Das selbe Problem zwischen diesen beiden Zeilen in deinem Code:

Delphi-Quellcode:

    if Assigned(aObj) then FreeAndNil(aObj);
    Liste.Delete(0); //auch Listeneintrag löschen

Am Ende der Methode ist ein definierter Zustand erreicht, das ist wichtig.

Zitat:

3. Das Clear, das im Destruktor von TList aufgerufen wird, ist kein Freifahrtsschein dafür, sich nicht vernünftig um die Elemente der Liste, gerade beim Freigeben, zu kümmern

Hat niemand behauptet.

Zitat:

4. Wird das schon in der Vorlesung "Grundlagen der Informatik" gelehrt und ist in der Informatik allgemeingültig

Was meinst du mit "das"?

Wer so was lehrt, hat Schläge verdient:

Delphi-Quellcode:

if Assigned(aObj) then FreeAndNil(aObj);

[spaxxn]

Zitat:

Zitat von Blup (Beitrag 1170692)

Delphi-Quellcode:

if Assigned(aObj) then FreeAndNil(aObj);

Wo habe ich mich darauf bezogen?

Lies mal lieber den Thread nochmal...

[spaxxn]

[QUOTE=Blup;1170692]

Zitat:

Das ist auch nicht notwendig und solche Zustände sind im Programmablauf nur schwer zu vermeiden.

Ich finde auch, dass ich mir zukünftig die Kontrolle über verwendeten Speicher sparen sollte. Dann wäre ich schneller fertig.

[DeddyH]

Könnte man mit so etwas leben (ich bin hier von der eingangs erwähnten Stringliste ausgegangen)?

Delphi-Quellcode:

procedure AllesFreigeben;
var
  i: integer;
begin
  for i := Liste.Count - 1 downto 0 do
    begin
      (Liste.Objects[i] as TMyObject).Free;
      (* die folgende Zeile macht eigentlich nur Sinn, 
         wenn die Liste an sich noch nicht freigegeben werden soll *)
      Liste.Delete(i);
    end;
  Liste.Free; //s.o.
end;

[spaxxn]

So oder halt mit while Count > 0 usw. Das würde die lokale Variable i noch einsparen.

[Bummi]

ich will ja an der Haarspalterei nicht wirklich teilhaben, aber ich kenne Fälle in denen die Liste (bei der Erstnennung eine Stringlist) nicht geleert werden soll.

[Progman]

Ich verstehe die ganze Diskussion nicht!
Ich habe nun mal 1985 mit Programmieren begonnen.
Und zwar mit ASM, dBase über Turbo Pascal und dann Delphi (2, 3, 4, 6, 2007).
Ich habe einfach gelernt, dass man bei Arbeit mit Objects alles was man selbst erzeugt auch selbst wieder freizugeben hat. Und diesen Stil behalte ich bis heute bei und habe damit nie unliebsame Überaschungen erlebt. Außerdem kann ich im Quelltext sehen, was geschieht. Es ist "lesbar" was passiert.
Ich weiß nicht, ob bei Freigabe einer TList auch alle in ihr enthaltenen Objects sauber freigegeben werden. Das kann nämlich in den verschiedenen Delphi-Versionen sehr unterschiedlich sein. Also mache ich das eben "von Hand" :)
Und wenn Anfänger das erstmal so lernen, sind sie immerhin auf der sicheren Seite zur sauberen Programmierung, weil das, was geschieht, auch anschaulich im Quellcode zu lesen ist.
Und im Übrigen ist es mir eigentlich egal, wie jemand meinen Programmierstil findet *g*
Ich habe im Laufe der letzten Jahre genug Programme geschrieben, von denen einige sogar in recht großen Stückzahlen verkauft wurden und sich dadurch auszeichnen, dass sie auf allen Systemen (ab XP aufwärts bis Win8) funktionieren.
Mein Delphi 2007 bleibt übrigens auch mein letztes Delphi. XE kommt für mich nicht mehr in Frage, da ich seit Januar Rentner bin und meine Tätigkeit stark einschränke :P

[DeddyH]

Zitat:

Zitat von Bummi (Beitrag 1170698)

ich will ja an der Haarspalterei nicht wirklich teilhaben, aber ich kenne Fälle in denen die Liste (bei der Erstnennung eine Stringlist) nicht geleert werden soll.

Bei TStringlist macht das ja auch noch Sinn, aber bei TList? Was soll ich mit einer Liste, die aus wilden Zeigern besteht, da kann ich ja gleich russisches Roulette spielen?

@Progman: TList gibt nichts frei, TObjectlist nur dann, wenn OwnsObjects gesetzt ist. Das ist auch richtig so, denn es kann ja auch sein, dass man nur Referenzen auf Objekte, die anderweitig verwaltet werden, in die Liste aufnehmen möchte. Da wäre es extrem blöd, wenn diese freigegeben würden und man davon außerhalb der Liste nichts mitbekommt ;)

[Progman]

Zitat:

Zitat von DeddyH (Beitrag 1170701)

.....
@Progman: TList gibt nichts frei, TObjectlist nur dann, wenn OwnsObjects gesetzt ist. Das ist auch richtig so, denn es kann ja auch sein, dass man nur Referenzen auf Objekte, die anderweitig verwaltet werden, in die Liste aufnehmen möchte. Da wäre es extrem blöd, wenn diese freigegeben würden und man davon außerhalb der Liste nichts mitbekommt ;)

Sorry, ich meinte TObjectList.
Und auch da hab ich meine Zweifel, ob das korrekt funktioniert, wenn ich in der Liste Objects habe, die wiederum TObjectLists beinhalten, in denen wieder Objecte sind, die auch noch TLists enthalten usw.
Da ist man einfach auf der sicheren Seite, für jedes Object im Destructor das Leeren der Listen durchzuführen. So können sich solche Listen beliebig tief verschachteln und werden immer über Free korrekt freigegeben, nachdem auch die "tiefer liegenden" TLists korrekt freigegeben und entfernt wurden.
Ich bin einfach kein Freund von Einzeiler-Code, der zwar mächtig sein mag, aber man nicht mehr sieht, was eigentlich passiert. Zumal der Compiler dafür ja doch den ganzen Code und die entsprechenden Schleifen generieren muss. Man sieht sie nur nicht mehr :lol:

[Iwo Asnet]

Zitat:

3. Das Clear, das im Destruktor von TList aufgerufen wird, ist kein Freifahrtsschein dafür, sich nicht vernünftig um die Elemente der Liste, gerade beim Freigeben, zu kümmern

Ich habe sie doch freigegeben...

Delphi-Quellcode:

For i:=0 to List.Count-1 Do List[i].Free;

Danach noch ein

Delphi-Quellcode:

List.Clear

und die Welt ist in Ordnung. Vollkommen.

Zitat:

4. Wird das schon in der Vorlesung "Grundlagen der Informatik" gelehrt und ist in der Informatik allgemeingültig

Was wird denn gelehrt? So etwas? Dann hast Du nicht aufgepasst und solltest den Kurs wiederholen. Schau aber beim nächsten Mal auf das Datum (1.April ist kein gutes Datum) und darauf, as Du nicht aus Versehen die Vorlesung "Grundlagen der Komik" besuchst. ;-)

Zitat:

Zitat von Progman (Beitrag 1170703)

Und auch da hab ich meine Zweifel, ob das korrekt funktioniert, wenn ich in der Liste Objects habe, die wiederum TObjectLists beinhalten, in denen wieder Objecte sind, die auch noch TLists enthalten usw.

Natürlich funktioniert das. Die Objektliste sorgt einfach selbst dafür, das die Objekte freigegeben werden und ruf 'Free' auf. Das ruft den Destruktor auf und wenn dort drin steht, das eine weitere Objektliste freigegeben wird, dann geht das Spiel wieder von Vorne los.

Zitat:

Da ist man einfach auf der sicheren Seite...

Dann programmierer non-VCL und sicherheitshalber (wegen der sicheren Seite) auch ganz ohne andere Units.

Zitat:

Ich bin einfach kein Freund von Einzeiler-Code, der zwar mächtig sein mag, aber man nicht mehr sieht, was eigentlich passiert.

Jede Prozedur, die Du aufrufst, ist 'Einzeiler-Code'. Du musst natürlich verstehen, was ein

Delphi-Quellcode:

MeineObjektListe.Clear

macht.

Ich halte es immer so: Wenn ich mir Code anschaue, prüfe ich, ob man es nicht einfacher hinbekommen kann. Dann prüfe ich die relevanten Stellen und finde so z.B. das die TObjectList ordentlich aufräumt. Eine TList natürlich nicht.

Ich sehe dann auch, das es Quark ist, ein Element einer Liste freizugeben (was vollkommen ok ist), und das Element dann aus der Liste zu entfernen (was hier überflüssig ist). Ich sehe dann eben auch, das es Quark ist, einen Zeiger auf eine Objektinstanz erst in eine lokale Variable zu kopieren, um das Objekt dann freizugeben. Oder (weil ich mir 'FreeAndNil' einmal genau angeschaut habe), das es überflüssig ist, vorher zu prüfen, ob der Pointer=Nil ist. Und außerdem merke ich, das FreeAndNil an sich hier überflüssig ist, denn wozu sollte die lokale Variable genullt werden, wenn sie beim nächsten Schleifendurchlauf eh wieder überschrieben wird und ich nie, aber auch wirklich nie in die Verlegenheit kommen werde, auf einen etwaig ungültigen Inhalt zuzugreifen.

Ach, und ganz am Ende sehe ich, das eine While-Schleife durch eine For-Schleife ersetzt werden kann.

Eigentlich sind das alles Dinge, die der Compiler zwecks Codeoptimierung fast selbst durchgeführt hätte.

Diese Klimmzüge haben zudem 0.0% Mehrwert. Wirklich keinen. Also, weg damit.

[BUG]

Zitat:

Zitat von Iwo Asnet (Beitrag 1170704)

Du musst natürlich verstehen, was ein

Delphi-Quellcode:

MeineObjektListe.Clear

macht.

Vorschlag zur Güte: (für andere Entwickler) möglicherweise überraschende Effekte kommentieren und/oder OwsObjects explizit setzten.

Delphi-Quellcode:

MeineObjektListe.OwnsObjects = true;
// ...
MeineObjektListe.Clear(); // gibt Listenelemente frei!

[Alex_ITA01]

Mensch, da habe ich ja eine Diskussion angestoßen :-)

Meine Frage ist jetzt dann folgende:
Was ist schneller/"effektiver" wenn ich das Objekt und den Listeneintrag löschen möchte?

Eine while Schleife über die ganze Liste und jedes Objekt freigeben und immer Liste.Delete(0) aufrufen (führt meines erachtens nach immer zum aufrücken der restlichen Objekte in der Liste)

oder

Eine for Schleife über die ganze Liste vom Anfang bis Ende der Liste und jedes freigeben und am Ende Liste.clear aufrufen?

Gruß

[Furtbichler]

Ich würde definieren, was implementiert werden soll:
1. Gib ein Element frei und entferne es aus der Liste.
2. Gib alle Elemente frei und lösche den Inhalt der Liste.

Für beide Methoden gilt die Eingangsbedingung: "Alle Elemente der Liste sind Instanzen gültiger Objekte". Dies ist gleichzeitig die Ausgangsbedingung, frei nach Sepp Herrberger: "Nach dem Spiel ist vor dem Spiel".

Salopp ausgedrückt: Wenn die Liste vorher 'sauber' war, muss sie es hinterher auch sein. Innerhalb der Methode wird diese Bedingung immer irgendwie verletzt werden. Dies ist jedoch nur dann von Bedeutung, wenn die Liste threadsicher implementiert werden soll. Aber dann umschließt man die Operationen mit einem kritischen Abschnitt.

Wichtig ist bei der Implementierung, das die vorher vereinbarten Bedingungen (Design by Contract) eingehalten werden.

Delphi-Quellcode:

(* Kein Original-Delphi, eher Pseudocode ohne Schnick-Schnack*)
Procedure TMyList.RemoveElement(Element : TObject);
Begin
  Assert (InnerList.IndexOf(Element)>=0,'Element is not a member of the list');
  InnerList.Remove(Element);
  Element.Free;
End;

Procedure TMyList.RemoveAllElements;
Var
  element : TObject;

Begin
  Foreach element in InnerList do element.Free;
  InnerList.Clear;
End;

Die TObjectList macht auch nichts anderes.

Leute, aber das ist sowas von banal. Das man sich darüber überhaupt in diesem Forum unterhält, ist schon grenzwertig. Wie lange braucht man dann für ein Projekt, wenn man sich schon bei diesem Kindercode nicht sicher ist?

[Progman]

Kleiner Hinweis: In älteren Delphi-Versionen (incl. Delphi 2007) gibt es kein Foreach.
Man darf nicht immer nur sich und seine superneue Delphi-Version als Maßstab nehmen :-D
Aber ich werd wohl in diesem Forum lieber nichts mehr schreiben, da man hier schreiben kann was man will, es treten immer irgendwelche Meckerer auf den Plan, die natürlich ALLES viel besser wissen und können....

[Iwo Asnet]

Zitat:

Zitat von Progman (Beitrag 1170790)

Kleiner Hinweis: In älteren Delphi-Versionen (incl. Delphi 2007) gibt es kein Foreach.

Zitat:

Zitat von Furtbichler (Beitrag 1170777)

Delphi-Quellcode:

(* Kein Original-Delphi, eher Pseudocode ohne Schnick-Schnack*)

Wer lesen kann... usw, und afaik gibt es selbst in Delphi XE3 kein Foreach. Dort wäre es 'For', aber darum geht es eh nicht.

Zitat:

Zitat von Progman (Beitrag 1170790)

Aber ich werd wohl in diesem Forum lieber nichts mehr schreiben, da man hier schreiben kann was man will, es treten immer irgendwelche Meckerer auf den Plan, die natürlich ALLES viel besser wissen und können....

So so, jemand mit einer anderen Meinung (oder mehr Ahnung) ist also ein 'Meckerer'. Komische Sichtweise.

Du hast deine Sichtweise dargelegt ("lieber auf die altmodische Tour aber [für Dich] auf Nummer sicher") und dagegen ist nichts einzuwenden. Man wird aber wohl noch auf die Scheuklappen aufmerksam machen dürfen, die man meint, bei dir zu sehen, oder?