Destructor notwendig bei class?

[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...For i:=0 to List.Count-1 Do List[i].Free; Danach noch ein 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 von Progman:

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 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 von Iwo Asnet:

Du musst natürlich verstehen, was ein 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
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 von Progman:

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

Zitat von Furtbichler:

(* 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 von Progman:

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?