Wo gebt ihr Objekte frei?

[NerdIII]

Hi, ich stoße beim Entwickeln immer wieder auf Probleme beim Umsetzen von OOP.
'Objekte da freigeben wo sie erzeugt werden.' heißt es so schön.
Nun sehe ich in Code von anderen (und auch von mir ab und zu) Methoden, die TStringLists oder TBitmaps erzeugen und zurückgeben. Soll nun die Klasse deren Methode ich aufrufe sich einen Pointer auf die Bitmap/Liste merken, damit sie den Speicher auch selbst wieder freigeben kann oder soll die aufrufende Stelle das tun. Und wie kennzeichne ich eine Methode am besten, damit klar wird, dass jemand der sie verwendet noch Speicher freigeben muss?
(Es gibt Beispiele, z.B. bei Formatierungsfunktionen in C, die den Rückgabewert selber verwalten und freigeben. Das macht das Entwickeln angenehm sorglos.)

Es gibt für mich 3 Möglichkeiten:
1. Methode erzeugt Objekt. 'Empfänger' muss sich um Freigabe kümmern.
+ kein unnötiger Speicherverbrauch
- kann übersehen werden
2. Methode erzeugt Objekt und hält eine Referenz darauf. Beim nächsten Aufruf wird es freigegeben und ein neues erzeugt (C-Style).
+ Aufrufer braucht sich keine Sorgen zu machen
- Immer nur ein Objekt zur Zeit kann verwendet werden, ausßer es gibt einen Kopierkonstruktor
- evtl. unnötiger Speicher, wenn das Objekt nur kurz verwendet wird
3. Aufrufer erzeugt Objekt und lässt es von Methode 'befüllen'.
+ keine Missverständnisse bei erfahrenen Entwicklern
- unübersichtlicher Code durch Erzeugung des Objekts und weiteren Parameter

Wie entwickelt ihr? Gibt es Standards?

[Bernhard Geyer]

Primär 3, Ab und zu 1 und statt 2 würde ich ein Singleton-Pattern verwenden.

[himitsu]

Die 2 nutze ich eigentlich recht selten.

Und bei den Anderen (1/3) ... jenachdem wie es mir am Besten vorkommt ... halt das was ich in dem Moment und für das vorliegende "Problem"/Projekt für besser/einfacher erachte.


PS: ich geb manchma Objekte/Speicher garnicht frei ... Delphi/Windows kümmert sich schon drum
(jedenfalls da wo ich weiß daß die beiden sich schon korrekt darum kümmern)

[Dax]

Im aktuellen Projekt des Informatikkurses, in dem ich bin, wird durchgängig 1 verwendet und die Freigabe "vergessen" (weil niemand weiß, wie - außer n paar, die zu faul dazu sind *hust*)

Wenn du statt Objekten Interfaces verwendest, ist das Freigabeproblem auch nahezu aus der Welt.

[Muetze1]

Als Faustformel wird meistens vermittelt: Das Objekt sollte auf der gleichen Ebene wieder freigegeben werden, wie es erzeugt wurde. Somit ist die erste Lösung nicht nutzbar und auch grundsätzlich schlechter Stil. Wenn in einem Projekt viele sowas machen, dann sieht im Endeffekt keiner mehr durch um sagen zu können: MethodeX gibt mir nur eine Referenz auf ein internes Objekt zurück, also nicht freigeben oder die Methode gibt ein frisch für die Rückgabe angelegtes Objekt zurück. Es macht deutlich mehr Aufwand und Pflege.

Meine XMLLib hatte solche Methoden z.T. wie dein erstes Beispiel implementiert, aber das war sehr schlecht. Die meisten Nutzer haben sich keine Platte gemacht die Rückgabewerte freizugeben. Zum Teil wurde die nichtmal in eine Variable geworfen sondern direkt temporär benutzt und da ist dann schnell mal die Applikation beim Speicher fressen. Die Anwender haben die Lib nicht geschrieben und wissen nicht um das Handling. Es gibt zwar eine Dokumentation, aber wer liest die, wenn alles läuft? Vor allem kommt keiner auf die Idee etwas frei zu geben, was ein anderer angelegt hat. Nun habe ich es durchgedrückt und der Aufrufer hat die Listen zu erzeugen. Damit ist es dem Nutzer definitiv bewußt, dass er eine Instanz angelegt hat und dadurch ist es ihm auch bewußt diese wieder freizugeben. Und wann das sein wird, weiß der Anwender am besten. Damit ist aber auch immer definitiv klar, wer was zu machen hat.

[arbu man]

OT: Als ich angefangen habe zu Programmieren wusste ich nicht, dass man Objekte freigeben muss/kann. Jedoch wenn man in einer for Schleife immer ein Bitmap lädt stößt man recht schnell an Grenzen.

Heute verwende ich oft 1.

Allerdings sehne ich mir machmal die Vorteile eines Garbage Collectors herbei

mfg, Björn

[himitsu]

http://www.dpunkt.de/java/Die_Sprach...t_Java/10.html

Dann doch lieber selbst freigeben

noch'n Thread für's aufräumen
und dann ist man nichtmal sicher ob der wirklich alles richtig aufräumt ....

[Christian Seehase]

Moin Nerd,

Zitat von NerdIII:

'Objekte da freigeben wo sie erzeugt werden.' heißt es so schön.

heisst es wo so schön?
Ich finde diese Aussage sehr unverständlich. Da gefällt mir die von Thomas doch erheblich besser.
Um die abstrakte Aussage mit der gleichen Ebene von Erzeugen und Löschen mal zu konkretisieren:

Wenn ich ein Objekt im initialization-Abschnitt erzeuge, wird es im finalization-Abschnitt wieder freigegeben
Wenn ich ein Objekt in einem Konstruktor erzeuge, wird es im zugehörigen Destruktor wieder zerstört.
Wenn ich ein Objekt in einer Prozedur/Methode erzeuge, wird es auch dort wieder freigegeben.
Bei letztgenanntem Falle sehe ich allerdings auch Ausnahmen:
Wenn ein Objekt erzeugt wird, dass dann in einer Liste vorgehalten wird (z.B. eine TObjectList) werden sie, natürlich, nicht gleich in der Prozedur/Methode wieder freigegeben (wobei diese Liste dann ja als Owner einer Komponente fungiert).
Die zweite Ausnahme die ich hier sehe, ist das Erzeugen einer Komponente, wenn hier im Constructor ein Owner angegeben wird, der dann ja für die Freigabe verantwortlich ist.

Sollte ich so ein global erzeugtes Objekt zwischendurch mal wieder leeren müssen, geschieht dies durch eine entsprechende Methode, und nicht durch Free und erneutes Create. Beispielsweise habe ich da ein Projekt, in dem ich ein paar StringListen immer wieder benötige. Die werden im OnCreate des Formulares erzeugt, im OnDestroy wieder freigegeben, und zwischendurch mit Clear immer mal wieder geleert.

Um das auf Deine drei Möglichkeiten anzuwenden:
Zu 1.:
Kommt überhaupt nicht in Frage, da hier viel zu leicht die Übersicht verloren gehen kann, und man sich leicht Speicherlöcher einhandelt. Stell Dir vor, dass passiert Dir in einem Dienst, der auf einem Server läuft...

Zu 2.:
Schon etwas besser als 1. aber wenn Du die angesprochende Kopiermethode verwendest muss sich doch wieder eine andere Stelle darum kümmern aufzuräumen. Ausserdem kann es Dir hier passieren, dass ein Programmteil noch mit einem Objekt arbeiten will, dass bereits durch den Aufruf der gleichen Methode in einem anderen Programmteil zerstört wurde. Aus diesem Grunde halte ich diese Möglichkeit für recht unübersichtlich.

Zu 3.:
Meiner Ansicht nach die sinnvollste Variante. Deinen Negativpunkt kann ich allerdings nicht nachvollziehen, eher im Gegenteil. Man sieht gleich woran man ist.

Ich würde diese Vorgehensweise übrigens nicht auf Objekte einschränken, sondern auf alle Resourcen anwenden die angefordert werden, z.B. auch Handles.
Es gibt übrigens sogar API-Funktionen, die Resourcen selber reservieren (z.B. viele NetXXX-Funktionen), und für die es explizit Funktionen gibt, mit denen diese vom Aufrufer wieder freizugeben sind.
Das dient dort übrigens nur dem Komfort sich nicht selber um erforderliche Buffergrösse kümmern zu müssen, wie bei so manch anderer API-Funktion.

[Popov]

Da brauchen wir nicht lange drumherum reden, die Methode 3 ist eigentlich die Standardmethode. Ich hatte noch nie eine Aufgabe die ich nicht mit dieser Methode lösen konnte. Sie ist sauber und man weiß immer was man freigeben muß.

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. Ich kann mich sogar erinnern irgendwo ein Beispiel in der Delphi Hilfe gesehen zu haben das so gelöst wurde. Das Problem ist allerdings, daß man irgendwann nicht mehr dran denkt, daß man etwas wieder freigeben muß. Bei Miniprojekten geht das noch, vielleicht auch bei Funktionen die man immer wieder nutzt, sonst bin ich aber kein Fan davon.

Die Methode 2 ist vielleicht interessant, aber das ist kein programmieren, sondern eher basteln. Meiner Meinung nach verläßt man hier den Pfad der sauberen Programmierung.

[Muetze1]

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. Ich kann mich sogar erinnern irgendwo ein Beispiel in der Delphi Hilfe gesehen zu haben das so gelöst wurde. Das Problem ist allerdings, daß man irgendwann nicht mehr dran denkt, daß man etwas wieder freigeben muß. Bei Miniprojekten geht das noch, vielleicht auch bei Funktionen die man immer wieder nutzt, sonst bin ich aber kein Fan davon.

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.