spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Was kannst du denn an dem MSDN Beispiel nicht nachvollziehen?

IDisposable hat im Prinzip die Funktion, eine Möglichkeit zu schaffen, eine Instanz zu einem festen Zeitpunkt zu "zerstören" (mir ist grad kein besseres Verb eingefallen...)

Wenn du z.B eine offene Datenbankverbindung hast oder eine Klasse, z.B. eine Textur o.ä., die viel Arbeitsspeicher verbraucht (und nicht verwaltete Ressourcen belegt) hast, und du die Verbindung im Destruktor schließt oder die Textur im Destruktor freigibst, hast du das Problem, das die Verbindung/Textur erst geschlossen/freigegeben wird, wenn der Garbage Collector sich dazu entschließt, die Instanz zu beseitigen, und dieser Zeitpunkt ist unbestimmt.

Genau deswegen gibt es IDisposable, denn damit wird einem eine einheitliche (weil interface ) Möglichkeit geboten, Ressourcen zu einem festgelegten Zeitpunkt freizugeben. Mit IDisposable kann man dann auch z.B. Gebrauch von using-Blöcken machen.

Also, .NET hat ja einen Garbage Collector. D.h. ab und an während dein Programm läuft guckt der nach welche Objekte noch in Benutzung sein könnten, da es noch Referenzen auf sie gibt, und gibt den Rest frei.

IDisposable kommt nun bei ein paar Fällen ins Spiel:

1) Dieses relativ zufällige freigeben reicht nicht. Das ist beispielsweise beim Umgang mit Dateien oder Netzwerkverbindungen der Fall. Die zuständigen Klassen stellen zwar typischerweise eine Close-Methode auf um die Resource deterministisch freizugeben, implementieren aber ebenso typischerweise auch IDisposable.

2) Es gibt Interop mit unmanaged Ressourcen. Diese kann der Garbage Collector nicht freigeben.

Evtl. gibt es noch mehr Fälle, die sind aber alle relativ ähnlich. Es geht immer um Ressourcen, die der Garbage Collector nicht freigeben kann oder wo der Zeitpunkt zu undefiniert wäre.

Fall 2 lässt sich auch theoretisch durch Finalizer behandeln. Finalizer haben aber einen Nachteil: Der GC kann das Objekt nicht direkt freigeben und gibt es erst in eine Finalizerqueue, die nach und nach auf einer CPU abgearbeitet wird. Sprich: Gibt es viele Finalizer, können die zu einem richtigen Performanceproblem werden.

Daher implementieren Klassen die einen Finalizer haben typischerweise IDisposable in dem typischen Stil wie man ihn immer wieder im MSDN findet. Falls der Programmierer Dispose aufruft, werden die gehaltenen Ressourcen sofort freigegeben und das Objekt wird so markiert, dass es nicht auf der Finalizerqueue landet. Falls der Programmierer das verschläft, wird irgendwann wohl der Finalizer zum Zuge kommen und dann halt die Ressourcen freigeben.

D.h. als Schlussfolgerung: Hält deine Klasse weder direkt noch indirekt solche Ressourcen, brauchst du IDisposable nicht zu implementieren.

Na wenn es deine sind, dann weißt du doch wann du welche Textur nicht mehr brauchst.

Zitat von »De_Struktor«

und was ist mit den Texturen und meinen eigenen Klassen, wie kann ich denn erkennen, ob sie nicht mehr gebraucht werden bzw ob noch Referenzen auf sie liegen??

Als Faustregel würde ich sagen, wenn Felder deiner Klasse unmanaged Ressourcen, die z.B. per P/Invoke bekommen hast, oder Objekte, die disposable sind, halten, dann solltest du IDisposable implementieren. Ansonsten solltest du es nicht tun und dann brauchst du dir keine Gedanken darüber zu machen, ob es noch Referenzen auf die Objekte gibt.

Solltest du doch mal IDispoable brauchen, nun, dann ergibt sich das aus Programmablauf. Wie bei unmanaged Sprachen, wann man ein Objekt deleten kann.

Bitte beachten, dass allein die Implementierung von IDisposable NICHT ausreichend ist, denn der Garbage-Collector ruft nicht von allein Dispose() auf. Das muss man explizit mit in den Destruktor rein schreiben. Anders verhält es sich natürlich bei der using-Direktive.