'interface IDisposable est utilisée par de très (trop) nombreuses classes
Mais t'as généralement pas besoin de les appeler.
A part dans des situations où tu fais de très nombreuses allocation d'objet auquel cas tu veux rendre très rapidement la mémoire, je vois pas l'intérêt. Tu fais pas de foreach(var i = 0;i++;i<1000000) new Form() si ?
Sur 50 classes que je développe, je dois implémenter IDisposable 1 fois.
Cas vécu d’un conteneur d’objet chargeant de très nombreux objets se désérialisant eux même depuis un flux XML ; un des types d’objet utilisés n’appelait pas le Dispose (du parseur XML et d’autres objets du Framework .Net), résultat : explosion au chargement.
Sur 50 classes que je développe, 90% expose l’interface IDisposable, car on ne sait jamais comment sera utilisée notre classe ; donc, si l’un des objets membres présente l’interface IDisposable, il faut faire de même.
Sur un exemple simple non, mais lorsque tu as de multiples références sur ta classe, tu fini par ajouter des AddRef et des Release sur tes classes pour gérer ton propre compteur de référence, sa tombé à 0 appelant la méthode Dispose (pour éviter un pénurie de ressource non-managées).
Je connais personne qui ai eu besoin de f1aire ça, mais admettons que tu es ce besoin. Expliques moi en quoi c'est différent en Java ou en Python, en quoi c'est moins technique vis-à-vis de ce problème.
Même conteneur d’objets gérant une arborescence d’objets qui peuvent se référencer l’un l’autre, au déchargement d’une partie de l’arborescence, le Dispose doit être appelé lorsque la dernière référence sur un objet est perdue. Si l’on attend le déclenchement du garbage collector (sans appelé Dispose), au chargement d’une autre partie de l’arborescence ça explose.
En Java, le garbage collector est beaucoup plus prompt à se déclencher, il y donc moins de problème ; en python, je ne sais pas, car je n’ai jamais construit de très grosse application en Python.
Et puis, ce n’est pas parce que le petit copain à des défauts, qu’il faut avoir les mêmes.
Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité.
On s'en fou c'est caché. Pour le développeur c'est toujours moins complexe que de gérer la mémoire à la main.
En C++ managé, le destructeur est quasiment l’équivalent du Dispose à l’exception prés qu’il appelle automatiquement le destructeur de la classe mère et qu’il ne s’appelle pas Dispose (mais vu d’autre langage comme C#, il s’appelle Dispose).
Donc lorsque l’on passe du C++ managé au C# et inversement, il faut faire super gaffe, ça n’apporte rien, mais ça complique encore un peu plus un truc déjà inutilisable.
Et pour certaines classes critiques (classes de base très utilisés), il est parfois fortement conseillé de gérer la mémoire et les ressources non-managé à la main en créant un objet mixte (C++ managé et C++ non-managé), si l’on veut avoir de très bonne performance. Ce n’est donc pas forcément masqué.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par Benoit . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
'interface IDisposable est utilisée par de très (trop) nombreuses classesMais t'as généralement pas besoin de les appeler.
A part dans des situations où tu fais de très nombreuses allocation d'objet auquel cas tu veux rendre très rapidement la mémoire, je vois pas l'intérêt. Tu fais pas de foreach(var i = 0;i++;i<1000000) new Form() si ?
Sur 50 classes que je développe, je dois implémenter IDisposable 1 fois.
Cas vécu d’un conteneur d’objet chargeant de très nombreux objets se désérialisant eux même depuis un flux XML ; un des types d’objet utilisés n’appelait pas le Dispose (du parseur XML et d’autres objets du Framework .Net), résultat : explosion au chargement.
Sur 50 classes que je développe, 90% expose l’interface IDisposable, car on ne sait jamais comment sera utilisée notre classe ; donc, si l’un des objets membres présente l’interface IDisposable, il faut faire de même.
Sur un exemple simple non, mais lorsque tu as de multiples références sur ta classe, tu fini par ajouter des AddRef et des Release sur tes classes pour gérer ton propre compteur de référence, sa tombé à 0 appelant la méthode Dispose (pour éviter un pénurie de ressource non-managées).Je connais personne qui ai eu besoin de f1aire ça, mais admettons que tu es ce besoin. Expliques moi en quoi c'est différent en Java ou en Python, en quoi c'est moins technique vis-à-vis de ce problème.
Même conteneur d’objets gérant une arborescence d’objets qui peuvent se référencer l’un l’autre, au déchargement d’une partie de l’arborescence, le Dispose doit être appelé lorsque la dernière référence sur un objet est perdue. Si l’on attend le déclenchement du garbage collector (sans appelé Dispose), au chargement d’une autre partie de l’arborescence ça explose.
En Java, le garbage collector est beaucoup plus prompt à se déclencher, il y donc moins de problème ; en python, je ne sais pas, car je n’ai jamais construit de très grosse application en Python.
Et puis, ce n’est pas parce que le petit copain à des défauts, qu’il faut avoir les mêmes.
Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité.On s'en fou c'est caché. Pour le développeur c'est toujours moins complexe que de gérer la mémoire à la main.
En C++ managé, le destructeur est quasiment l’équivalent du Dispose à l’exception prés qu’il appelle automatiquement le destructeur de la classe mère et qu’il ne s’appelle pas Dispose (mais vu d’autre langage comme C#, il s’appelle Dispose).
Donc lorsque l’on passe du C++ managé au C# et inversement, il faut faire super gaffe, ça n’apporte rien, mais ça complique encore un peu plus un truc déjà inutilisable.
Et pour certaines classes critiques (classes de base très utilisés), il est parfois fortement conseillé de gérer la mémoire et les ressources non-managé à la main en créant un objet mixte (C++ managé et C++ non-managé), si l’on veut avoir de très bonne performance. Ce n’est donc pas forcément masqué.