VB.NET Unterschied /Zusammenhange zwischen .Dispose() und = Nothing?
-
Hallo ihr,
Arbeite grad an einem kleinen VB .NET 2003 Projekt und bin Anfänger in der Materie.
Bin soweit das ich Objekte dynmaisch mit new, und will diese ohne des Carbage Colletor löschen a'la C++ (delete)
Nun bin ich auf zwei Möglichkeiten gestoßen, einmal der Referenz Nothing zuweisen, oder die Mehtode Dispose aufrufen?
was benutze ich nun wann? Versteh das nich ganz:)
Grüße
-
Bin mir nicht ganz sicher und hoffe ich erzähle hier nichts falsches. Also: Wenn du einer Refernz nothing zuweist "lebt" das objekt noch so Lange weiter (ohne Referenz) bis es vom Garbage Collector gelöscht wird. Mit Dispose() wird das objekt sofort gelöscht.
Ist ganz änlich wie bei C++, nur dass es da natürlich keinen GC gibt:Object obj = new Object(); //Objekt erzeugen obj = NULL; //Die referenz hat NULL, das Objekt existiert aber immer noch delete obj; //Löscht das Objekt wirklich und gibt den Speicher frei (Es darf natürlich nicht wie in diesem Fall NULL sein)
-
Naja, ist beides nicht richtig. Fakt ist, in VB.Net(und auch den anderen .Net Sprachen) kannst du Objekte nicht manuell löschen. Das macht immer, aber auch wirklich immer der GC. Wenn du ne Variable die auf ein Objekt zeigt auf Null setzt dann ists so wie Herb gesagt hat. Der GC erkennt das niemand mehr ne Referenz darauf hat und löscht die beim nächsten Durchlauf. Bei Dispose an sich wird nichts gelöscht, das hat nen anderen Hintergrund. Die Funktion Dispose kommt ja aus der IDisposable Schnittstelle und diese wird von Klassen implementiert die unmanaged Handles haben die erst noch freigegeben werden müssen bevor das Objekt zerstört werden kann. Genau das kommt in Dispose rein, und sobald der GC ein Objekt zerstören will, schaut er erst ob IDisposable implementiert ist, und falls ja, ruft er Dispose auf dass das Objekt noch sein unmanaged Zeug aufrufen kann, und beim nächsten Durchlauf wird des Objekt wie jedes andere vom GC weggeräumt. Dispose ist nur zum Aufräumen von unmanaged Zeug gedacht.
Hoffe jetzt ists bissle klarer, du brauchst dich gar nicht fragen wie du ein Objekt am besten zerstörst, weil das kannst du eh net
-
hehe .. naja wenn ich mit dem VB Projekt feritg bin, gehts wieder an C++;) da darf ich wieder löscehn;)
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?
-
Ist das überhaupt ein sauberes Arbeiten, wenn man die Schnittstelle IDisposable implementiert?
So richtigen Sinn sehe ich nämlich noch gar nicht darin. Wenn ich meine Ressourcen im Destruktor freigebe, sollte das doch reichen? Ich meine, der GC sucht dann das nicht mehr referenzierte Objekt, ruft den Destruktor auf und gibt anschließend die Resourcen des Objekts frei.
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?
mfg olli
-
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.