Destructor notwendig bei class?

[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:

if Assigned(aObj) then FreeAndNil(aObj);

[spaxxn]

Zitat von Blup:

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

[DeddyH]

Zitat von 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.

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 von DeddyH:

.....
@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

[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.