Ein Objekt in einer Funktion zerstören

[kagi3624]

Hallo, kann man das an eine Funktion übergebene Objekt auch dort zerstören, also sowas:

Code:

function myFunc (aClass : TMyClass) : bool;
begin
 result := false;
 class.Free;
 if not assigned(aClass) then
  result := true;
end;

[Klaus01]

.. kann man - aber was versprichst Du dir davon?

Ein Object sollte auf der "Ebene" freigegeben werden wo es auch erzeugt wurde.

Grüße
Klaus

[KodeZwerg]

Ich würde es auch in Schutzblöcke verfrachten.

Delphi-Quellcode:

procedure myFunc(aClass: TMyClass);
begin
  try
    //mach was mit dem objekt
  finally
    aClass.Free;
  end;
end;

[Uwe Raabe]

Mal abgesehen von den Einwänden meiner Vorredner enthält dein Programm sowohl einen syntaktischen als auch einen logischen Fehler:

1. class ist in Delphi ein reserviertes Wort und kann nicht als Name einer Variable verwendet werden. (Soll vermutlich aClass heißen)
2. Der Aufruf von Free führt in der Regel nicht dazu, dass ein nachfolgendes Assigned fehlschlägt.

[kagi3624]

Zitat von Klaus01:

.. kann man - aber was versprichst Du dir davon?

Ein Object sollte auf der "Ebene" freigegeben werden wo es auch erzeugt wurde.

Grüße
Klaus

Naja, meine erzeugte Klasse hängt von vielen verschiedenen Parametern und der Anzahl ab. Die Erzeugung habe ich also in überladene Funktionen ausgelagert. Ich glaub so macht man den Code nicht durch kilometerlange if else Konstrukte übersichtlicher, oder?

[KodeZwerg]

Benutze doch eine Liste um die erzeugten Class-Instanzen zu verwalten, jedenfalls mache ich das oft bei dynamisch erzeugten krams.

[kagi3624]

Zitat von KodeZwerg:

Benutze doch eine Liste um die erzeugten Class-Instanzen zu verwalten, jedenfalls mache ich das oft bei dynamisch erzeugten krams.

Kannst du ein Minimalbeispiel geben, bitte?

[himitsu]

Die wichtigsten Dinge wurden ja schon gesagt.
* falscher Bezeichner
* Free und in Beziehung dazu das Assinged

Wenn nicht noch mehr in dieser Funktionen ist, dann ist sie im Grunde total nnutzlos ... jedenfalls ist irgendwie kein "nützliches" Verhalten erkennen.

Und Spaß macht es, wenn man diese Funktion mehrmals aufruft,
denn Free setzt die Variable nicht auf NIL und selbst wenn, dann würde "dieser" Parameter den NIL außerhalb der Funktion verschwinden lassen.

Delphi-Quellcode:

function myFunc (aClass : TMyClass) : Boolean;
begin
  //Result := not Assigned(aClass);  // ob davor oder danach ist hier egal
  aClass.Free;
  Result := not Assigned(aClass);
end;

Würde Free die Variable auf NIL setzen (FreeAndNil), dann wäre Assing "danach" sinnlos, da es immer FALSE liefern würde.

[kagi3624]

hallo Himitsu, das war ja nur einen Beispiel, in meiner tatsächlichen Funktion wird ja was gemacht mit dem Objekt. Ich wollte nur wissen ob es im Prinzip geht, da ich irgendwie immer noch nicht verstehe ob die Funktionen in Delphi ein call by value oder call by reference machen.

[himitsu]

Ohne VAR kann die Variable außerhalb, beim Freigeben, nicht auf NIL gesetzt werden, damit auch spätere If-Assigned und Free-Aufrufe die bereits erfolgte Freigabe erkennen können.

Zitat:

call by value oder call by reference

Das ist ersmal egal.
Objekte sind immer Referenzen
und ob die "Variable" im Parameter als Referenz übergeben wird, das hängt von der Deklaration und der Größe des Typen ab.
VAR = immer Referenz
ohne = immer eine Kopie (ByValue)
const = hängt vom Typ ab (SizeOf>Pointer oder bei Size=Pointer, ob gemanagter Typ ala String und Interface)
const [ref] = immer referenz (bei Objekten also eine Referenz in einer Referenz)

Diesbezüglich hat sich aber in den letzten Jahren die Hilfe wesentlich verbessert, denn derartige Verhalten sind nun dokumentiert.
http://docwiki.embarcadero.com/RADSt...meter_(Delphi)
https://stackoverflow.com/questions/...ameters-useful