AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Delphi Destructor notwendig bei class?
Thema durchsuchen
Ansicht
Themen-Optionen

Destructor notwendig bei class?

Ein Thema von Alex_ITA01 · begonnen am 13. Jun 2012 · letzter Beitrag vom 14. Jun 2012
Antwort Antwort
Seite 1 von 2  1 2      
Iwo Asnet

Registriert seit: 11. Jun 2011
313 Beiträge
 
#1

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 11:53
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

Geändert von Iwo Asnet (13. Jun 2012 um 11:56 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von spaxxn
spaxxn

Registriert seit: 19. Nov 2004
253 Beiträge
 
Delphi XE2 Enterprise
 
#2

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 12:25
@Iwo: Das funktioniert, gebe ich Dir recht, aber ist mehr als unsauberer Stil.
"Hey Süße,
hol mir mal was zu trinken! Du wirst schon wieder hässlich!"

Zitat eines Betrunkenen
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.074 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 13:21
@Iwo: Das funktioniert, gebe ich Dir recht, aber ist mehr als unsauberer Stil.
Was ist die Begründung dafür?
  Mit Zitat antworten Zitat
Iwo Asnet

Registriert seit: 11. Jun 2011
313 Beiträge
 
#4

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 13:39
@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  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 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.
  Mit Zitat antworten Zitat
Benutzerbild von spaxxn
spaxxn

Registriert seit: 19. Nov 2004
253 Beiträge
 
Delphi XE2 Enterprise
 
#5

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 13:53
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.
"Hey Süße,
hol mir mal was zu trinken! Du wirst schon wieder hässlich!"

Zitat eines Betrunkenen

Geändert von spaxxn (13. Jun 2012 um 14:10 Uhr)
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.487 Beiträge
 
Delphi 12 Athens
 
#6

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 15:25
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);
  Mit Zitat antworten Zitat
Benutzerbild von spaxxn
spaxxn

Registriert seit: 19. Nov 2004
253 Beiträge
 
Delphi XE2 Enterprise
 
#7

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 15:32
if Assigned(aObj) then FreeAndNil(aObj);
Wo habe ich mich darauf bezogen?

Lies mal lieber den Thread nochmal...
"Hey Süße,
hol mir mal was zu trinken! Du wirst schon wieder hässlich!"

Zitat eines Betrunkenen

Geändert von spaxxn (13. Jun 2012 um 15:34 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.659 Beiträge
 
Delphi 12 Athens
 
#8

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 15:44
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;
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von spaxxn
spaxxn

Registriert seit: 19. Nov 2004
253 Beiträge
 
Delphi XE2 Enterprise
 
#9

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 15:43
[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.
"Hey Süße,
hol mir mal was zu trinken! Du wirst schon wieder hässlich!"

Zitat eines Betrunkenen
  Mit Zitat antworten Zitat
Progman

Registriert seit: 31. Aug 2007
Ort: 99974 MHL
695 Beiträge
 
Delphi 10.1 Berlin Starter
 
#10

AW: Destructor notwendig bei class?

  Alt 13. Jun 2012, 15:50
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
Karl-Heinz
Populanten von Domizilen mit fragiler, transparenter Aussenstruktur sollten sich von der Translation von gegen Deformierung resistenter Materie distanzieren!
(Wer im Glashaus sitzt sollte nicht mit Steinen werfen)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


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 23:53 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