So, ich habe jetzt mal ein bißchen weiter ausprobiert und komme zu einer Frage, bei der ich Euch wahrscheinlich bis hierhin lachen höre
Wenn ich eine Function habe, die als Rückgabewert einen Stream hat, wird dann der Streaminhalt oder nur der Pointer zurückgegeben?
Ich habe bislang in der aufrufenden Procedure immer eine Variable vom Type T(Memory)Stream created, ihr die Funktion zugewiesen und am Ende der Procedure freigegeben. Aber wenn nur der Pointer übergeben wird, darf ich den Stream in der aufrufenden Procedure gar nicht createn, oder? Der würde ja dann im nirgendwo verschwinden...
Und dann wäre e logisch, warum ich den Stream, obwohl an Result übergeben, nicht free setzen darf.
Ist das so, dann muss ich einiges überdenken...
LG Patrick
Wie Sebastian sagte gibt die Funktion eine Referenz (Pointer) auf das Objekt zurück.
Generell ist so eine Funktion problematisch vom Design her, da nicht klar ist, wer denn nun die Lebensdauer des zurückgegebenen Objektes verwaltet.
Erzeugt die Funktion das Objekt und der Caller muss es freigeben? Dann sollte die Funktion einen Namen haben, der das klar macht: CreateXYZ z. B. In einem solchen Fall ziehe ich es vor, statt einer Function eine Procedure mit einem const Parameter zu verwenden, dem der Caller das von ihm erzeugte Objekt übergibt. Dann ist klar, wer sich drum kümmern muss.
Gibt die Funktion eine Referenz auf ein existierendes Objekt zurück, dessen Lebenszeit anderswo verwaltet wird? Dann darf der Caller es natürlich
nicht freigeben und die Funktion sollte z. B. GetXYZ heißen.
Das ganze Problem läßt sich entschärfen, wenn man konsequent mit Interface-Referenzen anstatt mit Objektreferenzen arbeitet. Damit wird die Lebenszeit per reference counting automatisch verwaltet und man muss sich nicht selbst drum kümmern. Dafür hat man dann andere Probleme an der Backe, wie zirkuläre Referenzen zwischen Objekten via Interfaces die den reference count nie auf 0 sinken lassen.
