Wo gebt ihr Objekte frei?

[Christian Seehase]

Moin Popov,

Zitat von Popov:

Die Methode 1 mag ich eigentlich nicht, ist aber möglich. Hier will ich mal Muetze1 ein wenig widersprechen, denn diese Methode sieht man gelegentlich. Auch in gut programmierten Programmen.

Das ist ja eigentlich ein Widerspruch in sich

[DeddyH]

Was sind denn "gut programmierte Programme" bzw. Kriterien dafür?

[Popov]

Zitat von Muetze1:

z.B: TListView.Items.Add

ABER: Das TListView macht dies so, damit der Parent eingetragen ist. Der ListView kümmert sich auch um die zurück gegebenen Instanzen. Also genau eins dieser Ausnahme-Beispielen von Christian.

Nein, daß meinte ich eigentlich nicht, auch wenn das die Methode ist. Ich meinte wirklich sowas in der Art:

Delphi-Quellcode:

function BildLaden(FileName: TFileName): TBitmap;
begin
  Result := TBitmap.Create;
  Result.LoadFromFile(FileName);
end;

Jetzt nicht das, aber irgendwas in der Richtung.

[DataCool]

Hi,

eigentlich geht bei sauberer Programmierung kein Weg an Punkt 3 vorbei.
Ansonsten kann ich nur absolut Christian S. zustimmen,
hätte es nicht besser ausdrücken können

Die obere Function "Bild laden" ist in meinen Augen ein absolutes "no go"!
Falls ich sowas im Source Code einer Bewerbung sehe, landet die schonmal im Papierkorb !

Dann eher:

Delphi-Quellcode:

function BildenLaden(sFilename : TFilename; TargetBmp : TBitmap) : boolean;
begin
  result := false;
  if not Fileexist(sFilename) then exit;
  if not Assigned(TargetBmp) then exit;
  try
    TargetBmp.LoadfromFile(sFilename);
    result := true;
  except {} end;
end;

procedure bild_xyz;
Var tmpBmp : TBitmap;
begin
  tmpBmp := TBitmap.create;
  try
    if BildLaden(sFilename, tmpBmp) then 
      BildAnzeigen(tmpBmp);
  finally
    FreeAndNil(tmpBmp);// oder tmpBmp.free
 end;
end;

Aber bei diesem Beispiel könnte man ja nach dem Code "aussen rum",
auch eine eigene Klasse schreiben die das Bitmap als private var hat.
In diesem Fall würde das Bitmap im Constructor erzeugt,
im Destructor zerstört/freigegeben
und die Klasse hätte die Methoden LoadFromFile, LoadFromStream, Clear Display etc.

@arbu man:
Wenn man sauber programmiert,
dann brauch man den Garbage Collector nicht !!!
^^^^^^Ein Grund warum ich Java nicht mag und so gut wie gar nicht benutze.
Ich möchte Speicher immer nur dann reservieren, benutzen wenn ich ihn brauche und
wenn er nicht mehr benötigt wird, soll er auch umgehend freigegeben werden.
Es ist zwar schön wenn Mann sich darum nicht kümmern muss und einfach
"seinen Müll" vor die Tür stellt und wartet das er abgeholt wird.
Nur umso schlimmer wenn die Müllabfuhr nicht oder zu spät kommt.

Greetz DataCool

[Christian Seehase]

Moin DataCool,

wobei ich da noch einen kleinen Verbesserungsvorschlag hätte:
TargetBmp sollte besser als const deklariert werden.
Es funktioniert zwar so auch, aber wenn mal jemand daran arbeitet könnte, ohne Compilerwarnung, etwas in den Parameter geschrieben werden, so dass man dann zum einen ein Speicherleck bekommen kann, und sich zum anderen erst einmal wundert, warum's nicht wie erwartet funktioniert.
In einem anderen Thread hatte ich gerade gestern geschrieben, dass ich nur var- oder const-Parameter verwende.
Var bei Rückgabewerten (die ggf. zu Beginn natürlich auch Eingabewerte enthalten können), const bei reinen Eingabewerten, oder wenn Referenzen übergeben werden sollen.
Für Wert-Parameter habe ich bislang keine rechte Verwendung gefunden

Zum Thema Garbage-Collection:
Ich weiss nicht, wie gut die heutzutage implementiert ist, aber meinen Schneider Zeiten (CPC 464, Basic mit Garbage-Collection) war es immer eine mittlere Katastrophe, wenn die GC zugeschlagen hat. Der Rechner war dann immer für längere Zeit ausser Gefecht gesetzt, bis ihm wieder Reaktionen zu entlocken waren
Das sollte bei den heutigen Multi-Tasking-Systemen aber wohl kein Thema mehr sein.

[Muetze1]

@DataCool: Eine leerer except Block ist aber genauso unsittlich und würde auch den Weg in den Papierkorb finden

Und FreeAndNil() auf lokale Variablen (und das noch im Finally-Block am Ende der Procedure) ist auch schon mehrfach diskutiert worden - mit unterschiedlichem Ergebnis.

Zitat von Christian Seehase:

Var bei Rückgabewerten (die ggf. zu Beginn natürlich auch Eingabewerte enthalten können), ...

Genau bei dem Fall, dass sie keine Eingabewerte mitbringen, nutze ich out, ist schließlich dafür gedacht. Ansonsten 100% ACK zu deinen Ausführungen.

[Tyrael Y.]

Alle drei Varianten sidn ok und von Fall zu Fall auch sinnig.

Meistens benutze ich Fall 3, manchmal Fall 2 und eher selten Fall 1.


Zu Fall 1 noch eine Anmerkung.
Ich finde, wenn man diese Variante benutzt sollte die Klasse, die das Objekt in
seiner Methode zurückgibt auch eine Methode besitzen, um diese Objekt frezugeben.

Delphi-Quellcode:

function TEineKlasse.ErzeugeEinObject(): TEineAndereKlasse;
begin
 ...
end

procedure TEineKlasse.GibObjectWiederFrei();
begin
 ...
end;

Wenn man ein Objekt erhält, daß nur einmal existieren darf, sorgt die Methode
"GibObjectWiederFrei" dafür, daß genau dieses Objekt freigegeben wird.

Hat man den Fall, daß diese Klasse immer wieder neue Objekte erzeugen kann,
dann sollte die Klasse selbst eine Referenz zu jedem erzeugten Object in einer Liste halten und
beim Aufruf von "GibObjectWiederFrei" könnte man dann entweder den Index des
Objektes übergeben oder das Objekt selbst...

Ich finde alle Varianten sind Geschmackssache und jedes hat seine Lebensberechtigung.

Im normalen Programmieralltag wird man aber bevorzugt Variante 3, seltener Variante 2 und ganz selten Variante 1 benutzen. Ich und meine Kollegen machen das zumindest so.

[NerdIII]

Mit so einer regen Diskussion hatte ich garnicht gerechnet. Ich habe alle Antworten gespannt durchgelesen und bin nun zu dem Schluss gekommen, dass wenn mehrere Programmierer an dem Projekt arbeiten sollen Variante 3 fast immer zu bevorzugen ist.
Ich hatte in einem Projekt vor kurzem den Fall, Variante 2 verwendet wurde und ich fälschlicherweise das Objekt freigegeben habe.

Delphi-Quellcode:

tmpBMP := Objekt.GetRendering;
try
  imgBild.Picture.Bitmap := tmpBMP;
finally
  tmpBMP.Destroy;
end;

(TImage verwendet für dir Zuweisung ein Assign, deshalb keine Probleme an der Stelle)
Gelößt sah es dann so aus:
imgBild.Picture.Bitmap := Objekt.GetRendering; Variante 3 würde daraus folgendes machen:
Objekt.RenderInto( imgBild.Picture.Bitmap ); Das ist kürzer, unmissverständlich, erzeugt keine unnötige Bitmap und man bekommt das Objekt das etwas tut an den Anfang der Code-Zeile. Klarer Fall

[Popov]

Zitat von Christian Seehase:

wobei ich da noch einen kleinen Verbesserungsvorschlag hätte:
TargetBmp sollte besser als const deklariert werden.

Vielleicht verstehe ich dich nur falsch und du meinst etwas anderes (sorry, ich hatte heute noch kein Kaffee), aber TargetBmp ist nur Objektadresse. Weder wird etwas dran verändert, noch wird eine neue Adresse zurückgegeben. Es ergibt sich also aus der Sache, daß TargetBmp eine Konstante ist. Allerdings verstehe ich auch nicht wieso man es deshalb als Konstante deklarieren sollte. Erwartest du, daß einer sie in der Funktion frei gibt und sie dann für ein StringList nutzt? Wenn einer TargetBmp freigeben oder mißbrauchen würde, würde auch Const die Katastrophe nicht mehr abwenden können, denn das Objekt wäre sowieso im Speicher zerstört. Ob die Adresse dann innerhalb der Funktion immer noch auf die alte Stelle zeigen, wäre letztendlich egal. Const würde also nichts bringen. Aber wie gesagt, ich hatte noch nicht meinen Kaffee.

Und nochmal allgemein zu FreeAndNil (also nicht @Christian). Ich halte FreeAndNil für eine Unsitte. Ich arbeite schon so lange mit Objekten, aber es ist mir noch nie ... ups, das Objekt ist ja schon freigegeben ... passiert. Fehler können passieren, aber jenseits der Fehler weiß ich immer was mein Objekt macht. Mir ist schon klar, daß man gelegentlich auch abfragt ob ein Objekt Nil ist. Allerdings sind das dann Sondersituationen. In diesem Fall kann man meinetwegen das Objekt nil setzten, damit man an einer anderen Stelle prüfen kann ob es nil ist. In diesem Fall ist es ein Teil der Programmierung, denn Nil ist auch eine Information und wenn man mit dieser Information arbeiten muß oder will, dann nutzt man sie. Dann allerdings bewusst. Aber so oft kommt sowas nicht vor, also wozu das Ganze (beinahe hätte ich "Unsinn" gesagt)? Anscheinend ist es eine Mode, wie vor einigen Jahren der Gummiüberzug für die Fernbedienung. Plötzlich hatte für einen gewissen Zeitraum die gesamte Republik ihre Fernbedienungen mit einem Gummipolster geschützt, für den Fall, daß die Fernbedienung auf den Boden fällt. Plötzlich gab es kein Gummi für die Autoreifen, weil alle ihre Fernbedienungen schützten. Also wozu dieses Nil bei der Freigabe von Objekten? Wer nutzt ein Objekt das bereits freigegeben worden ist? Wer FreeAndNil nutzt, der mag auch die Methode zwei, denn da muß man wirklich wissen ob ein Objekt bereits freigegeben worden ist und auf das kann man mit Nil hinweisen. Ansonsten überlege ich wirklich wo man das in der Allgemeinprogrammierung anwenden kann. In besonderen Situationen meinetwegen, aber sonst?

[jbg]

Zitat von NerdIII:

tmpBMP.Destroy;

Was steht da nochmal in der Delphi-Hilfe über das direkte Aufrufen von Destroy? (rhetorische Frage, also bitte keine Antworten dazu außer einer weiß nicht was in der Delphi-Hilfe dazu steht. Dann kann er das aber auch selbst nachschlagen)