?
Vertex schrieb:
Was hat dann Dispose für einen Sinn? Schließlich kann der GC mit GC.Collect() angeregt werden, da muss doch der Benutzer nicht explizit die Ressourcen durch Dispose freigeben?
Ich bin mal so frei und zitiere aus der Dokumentation.
Visual C++ Concepts: Porting and Upgrading/Changes in Destructor Semantics schrieb:
Non-deterministic Finalization
Before the memory associated with an object is reclaimed by the garbage collector, an associated Finalize() method, if present, is invoked. You can think of this method as a kind of super-destructor since it is not tied to the program lifetime of the object. We refer to this as finalization. The timing of just when or even whether a Finalize() method is invoked is undefined. This is what is meant when we say that garbage collection exhibits non-deterministic finalization.
Non-deterministic finalization works well with dynamic memory management. When available memory gets sufficiently scarce, the garbage collector kicks in and things pretty much just work. Under a garbage collected environment, destructors to free memory are unnecessary. It's kind of spooky when you first implement an application and don't fret over each potential memory leak. Acclimation comes easy, however.
Non-deterministic finalization does not work well, however, when an object maintains a critical resource such as a database connection or a lock of some sort. In this case, we need to release that resource as soon as possible. In the native world, that is done through the pairing of a constructor/destructor pair. As soon as the lifetime of the object ends, either through the completion of the local block within which it is declared or through the unraveling of the stack because of a thrown exception, the destructor kicks in and the resource is automatically released. It works very well, and its absence under Managed Extensions was sorely missed.
The solution provided by the CLR is for a class to implement the Dispose() method of the IDisposable interface. The problem here is that Dispose() requires an explicit invocation by the user. This is error-prone and therefore a step backwards. The C# language provides a modest form of automation through a special using statement. The Managed Extensions design, as I already mentioned, provided no special support at all.
GC.Collect ruft vereinfacht gesagt den Finalizer der nicht referenzierten Objekte auf und gibt diese frei. Dispose hingegen wird nicht vom GC aufgerufen. Es gibt die Ressourcen des Objektes frei und markiert dieses mit GC.SuppressFinalize, d.h. der Finalizer wird bei der Löschung durch den GC nicht mehr ausgeführt. Wichtig ist nun, dass der Zeitpunkt, an welchem der GC die Objekte löscht, nicht bekannt ist. Du kannst nicht vorhersagen, wann dies passiert. Deshalb brauchst du Dispose.
BorisDieKlinge schrieb:
D.h. wenn ich Objekte in VB
Dim ObjRef as TEXT = new TEST();
erzeugen, muss ich eigentlich dispose und nothing nich am ende aufrunfen, das macht mit dann das VB irgendwann mal:) odER?
Solange du nicht irgendwelche systemkritischen Dinge anforderst (etwa Threads, File-Handles usw) kümmerst du dich am besten gar nicht darum.