Liste häufig füllen und leeren



  • Hallo!

    Ich habe hier eine Liste die ich oft befülle und dann wieder komplett lösche und wieder neu befülle und mache das im Moment so:

    someList.Add(New someClass(someParameters))
    

    und dann später

    someList.Clear()
    

    Muss ich mir da Sorgen machen wegen der vielen New und Clear() aufrufen?
    Ich habe da irgendwie das Gefühl, dass Speicher flöten geht(ja, ist wohl von c/c++ bei mir hängen geblieben).

    Danke!



  • Da geht kein Speicher flöten, solange someClass nicht IDisposable implementiert. Falls doch -> Dispose() für jedes Objekt aufrufen.



  • qweasdyxc schrieb:

    Da geht kein Speicher flöten, solange someClass nicht IDisposable implementiert. Falls doch -> Dispose() für jedes Objekt aufrufen.

    Was hat das denn mit IDisposable zu tuen?

    🙄


  • Administrator

    Firefighter schrieb:

    qweasdyxc schrieb:

    Da geht kein Speicher flöten, solange someClass nicht IDisposable implementiert. Falls doch -> Dispose() für jedes Objekt aufrufen.

    Was hat das denn mit IDisposable zu tuen?

    🙄

    Wenn die Klasse IDisposable implementieren und er nicht Dispose aufruft, dann ist die Chance gross, dass Speicher flöte gehen kann? 😉

    Grüssli



  • Dravere schrieb:

    Wenn die Klasse IDisposable implementieren und er nicht Dispose aufruft, dann ist die Chance gross, dass Speicher flöte gehen kann? 😉

    Aber auch nur, wenn es sich um unmanaged Speicher handelt 😛 Irgendwann läuft der GC schon und dann werden die managed Objekte ja plattgemacht.



  • GPC schrieb:

    Dravere schrieb:

    Wenn die Klasse IDisposable implementieren und er nicht Dispose aufruft, dann ist die Chance gross, dass Speicher flöte gehen kann? 😉

    Aber auch nur, wenn es sich um unmanaged Speicher handelt 😛 Irgendwann läuft der GC schon und dann werden die managed Objekte ja plattgemacht.

    Danke, genau.



  • Dumme Frage: Warum kann das bei Unmanaged Speicher Probleme machen, wenn diese in einem Managed Objekt im Dispose freigegeben werden? Dadurch, dass der GC irgendwann die Managed Objekte abräumt, wird doch dann auch automatisch Dispose aufgerufen und damit wird alles sauber aufgeräumt. Was übersehe ich?



  • KPC schrieb:

    Dumme Frage: Warum kann das bei Unmanaged Speicher Probleme machen, wenn diese in einem Managed Objekt im Dispose freigegeben werden? Dadurch, dass der GC irgendwann die Managed Objekte abräumt, wird doch dann auch automatisch Dispose aufgerufen und damit wird alles sauber aufgeräumt. Was übersehe ich?

    Der GC ruft Dispose nicht auf, sondern den Finalizer der Klasse und der sollte Dipose aufrufen um auf Nummer sicher zu gehen.



  • Naja, es gibt aber nur sehr wenige die mit Finalizern arbeiten.

    - Mein Abteilungsleiter sieht das zum Beispiel auch nicht gern. -



  • GPC schrieb:

    Irgendwann läuft der GC schon und dann werden die managed Objekte ja plattgemacht.

    Aber möglicherweise nicht, bevor die Allokation einer solchen Ressource fehlschlägt, weil alle von teils unerreichbaren Objekten belegt sind.



  • inflames2k schrieb:

    Naja, es gibt aber nur sehr wenige die mit Finalizern arbeiten.

    - Mein Abteilungsleiter sieht das zum Beispiel auch nicht gern. -

    Wenn man unmanaged-Ressourcen hat und das Dispose-Pattern korrekt implementieren möchte, muss man aber Finalizer benutzen (und ich sehe auch gar kein Problem damit).



  • Firefighter schrieb:

    GPC schrieb:

    Dravere schrieb:

    Wenn die Klasse IDisposable implementieren und er nicht Dispose aufruft, dann ist die Chance gross, dass Speicher flöte gehen kann? 😉

    Aber auch nur, wenn es sich um unmanaged Speicher handelt 😛 Irgendwann läuft der GC schon und dann werden die managed Objekte ja plattgemacht.

    Danke, genau.

    Ausser die Objekte "rooten" sich selbst. Wie z.B. laufende Timer und so Sachen. Dann werden die nie collected und du bist angeschissen. (Bzw. der User deines Programms.)



  • GPC schrieb:

    inflames2k schrieb:

    Naja, es gibt aber nur sehr wenige die mit Finalizern arbeiten.

    - Mein Abteilungsleiter sieht das zum Beispiel auch nicht gern. -

    Wenn man unmanaged-Ressourcen hat und das Dispose-Pattern korrekt implementieren möchte, muss man aber Finalizer benutzen (und ich sehe auch gar kein Problem damit).

    Das Dispose Pattern ist so ziemlich der grösste Quatsch den MS bei .NET verbrochen hat.

    Und mit Finalizern kommt man bei der Verwendung von disposable Klassen überhaupt nicht in Berührung.

    ----

    Die (viel) bessere Alternative zum Dispose Pattern:
    NIEMALS von Klassen ableiten die direkt unmanaged Resourcen halten und daher einen Finalizer haben, sondern IMMER nur über Aggregation einbinden.
    Dazu muss man u.U. etwas "umdesignen" - kleine "RAII" Hilfsklassen basteln die nur die unmanaged Resource kontrollieren und sonst nix.

    Ableiten kann man dann von der Klasse die bloss eine Referenz auf diese Resourcen-Besitzer-Hilfsklasse hält. Die braucht dann keinen Finalizer mehr, und man kann einfach Dispose ganz normal implementieren und ggf. in der abgeleiteten Klassen überschreiben.

    Und wenn in der abgeleiteten Klasse weitere unmanaged Resourcen dazukommen, dann kann man weitere Resourcen-Besitzer-Hilfsklasse per Aggregation einbinden -> immer noch kein Finalizer in der abgeleiteten Klasse nötig.

    Das ganze führt auch automatisch zu einer besseren Trennung der Zuständigkeiten. Das Dispose-Pattern dagegen lädt geradezu dazu ein Zuständigkeiten zu vermischen. FAIL.

    Es sind Ausnahmefälle vorstellbar wo das nicht funktioniert, weil man z.B. im Finalizer von einer Resourcen-Besitzer-Hilfsklasse Informationen über eine andere Resourcen-Besitzer-Hilfsklasse des selben Aggregats braucht. Ist mir aber ehrlich gesagt noch nie passiert. Und wenn es mir mal passiert, dann überlege ich mir für genau diesen Fall etwas wie man das ganze sauber lösen kann ohne gleich mit dem Dispose-Pattern Holzhammer draufzuhauen.

    ----

    Dem User der Klassen kann das aber wie gesagt völlig egal sein. Der muss nur wissen ob er eine Klasse disposen muss (wie z.B. laufende Timer), oder lediglich disposen kann wenn er mag (wie z.B. MemoryStream s).



  • hustbaer schrieb:

    GPC schrieb:

    inflames2k schrieb:

    Naja, es gibt aber nur sehr wenige die mit Finalizern arbeiten.

    - Mein Abteilungsleiter sieht das zum Beispiel auch nicht gern. -

    Wenn man unmanaged-Ressourcen hat und das Dispose-Pattern korrekt implementieren möchte, muss man aber Finalizer benutzen (und ich sehe auch gar kein Problem damit).

    Das Dispose Pattern ist so ziemlich der grösste Quatsch den MS bei .NET verbrochen hat.

    Es ist leider nicht besonders intuitiv. Ich vergess auch ständig, wie ich es korrekt implementieren muss 😃 An der Stelle ist C++ wirklich deutlich simpler. Aber na ja, was soll's.


Anmelden zum Antworten