Résultat, il est nécessaire d’appeler manuellement le destructeur des objets
Non. Tu as besoin de le faire uniquement quand tu veux libéré instantanément la ressource. Dans les 3/4 des cas tu n'as pas besoin de le faire, sans parler du fait que la grande majorité des objets .NET n''implémentent pas IDisposable parcqu'ils n'ont pas besoin de le faire. Enfin l'interface IDisposable est là pour libérer des ressources qui ne sont pas gérées par le garbage collector mais des ressources natives ou des fichiers par exemple : bref c'est loin d'être le cas général pour les objets .NET.
L'interface IDisposable est utilisée par de très (trop) nombreuses classes (IHM, parseur XML, ...)
MS n’a pas voulu appeler le destructeur des objets lorsque leur compte de référence tombe à 0 et le fait dans le garbage collector
En même temps c'est le garbage collector qui compte les références donc bon...
On voit bien la limite de ce choix avec la gestion ubuesque du Dispose, un garbage collector pourrait se limiter à empêcher la fragmentation de la mémoire.
Et franchement c'est loin d'être "technique" et compliqué de faire un :
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).
En C++ tu trouves ca simple et pas technique ces méthodes virtuelles appelées dans un destructeur si on fait pas attention ?
Si, mais là tu as les mêmes règles pour tout les objets (alors quand .Net : Dispose ou pas, destructeur appelé n’importe quand, ...) et donc des réflexes systématiques évitant toute erreur.
il est exécuter dans le contexte du garbage collector, ce qui empêche par exemple la libération les domaines d’application
Non,c'est un autre problème le CLR n'autorise pas de libérer de domaines d'application tout court, un manque fonctionnel. D'ailleur .NET 4 évolue et propose cette fonctionnalité.
Ah, AppDomain::Unload : http://msdn.microsoft.com/fr-fr/library/system.appdomain.unl(...)
avec la super phrase :
Dans certains cas, l'appel à Unload provoque une exception CannotUnloadAppDomainException immédiate, par exemple si l'appel est effectué dans un finaliseur.
Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité. J'aime bien le passage:
If your type has a destructor, the compiler will generate a Dispose method that implements IDisposable. If a type authored in Visual C++ with a destructor is consumed from another language, calling IDisposable::Dispose on that type will cause the type's destructor to be called. When consumed from a Visual C++ client, you cannot directly call Dispose; call the destructor instead using the delete operator.
If your type has a finalizer, the compiler will generate a Finalize(void) method that overrides Finalize.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par Benoit . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Résultat, il est nécessaire d’appeler manuellement le destructeur des objetsNon. Tu as besoin de le faire uniquement quand tu veux libéré instantanément la ressource. Dans les 3/4 des cas tu n'as pas besoin de le faire, sans parler du fait que la grande majorité des objets .NET n''implémentent pas IDisposable parcqu'ils n'ont pas besoin de le faire.
Enfin l'interface IDisposable est là pour libérer des ressources qui ne sont pas gérées par le garbage collector mais des ressources natives ou des fichiers par exemple : bref c'est loin d'être le cas général pour les objets .NET.L'interface IDisposable est utilisée par de très (trop) nombreuses classes (IHM, parseur XML, ...)
MS n’a pas voulu appeler le destructeur des objets lorsque leur compte de référence tombe à 0 et le fait dans le garbage collector
En même temps c'est le garbage collector qui compte les références donc bon...
On voit bien la limite de ce choix avec la gestion ubuesque du Dispose, un garbage collector pourrait se limiter à empêcher la fragmentation de la mémoire.
Et franchement c'est loin d'être "technique" et compliqué de faire un :
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).
En C++ tu trouves ca simple et pas technique ces méthodes virtuelles appelées dans un destructeur si on fait pas attention ?
Si, mais là tu as les mêmes règles pour tout les objets (alors quand .Net : Dispose ou pas, destructeur appelé n’importe quand, ...) et donc des réflexes systématiques évitant toute erreur.
il est exécuter dans le contexte du garbage collector, ce qui empêche par exemple la libération les domaines d’application
Non,c'est un autre problème le CLR n'autorise pas de libérer de domaines d'application tout court, un manque fonctionnel. D'ailleur .NET 4 évolue et propose cette fonctionnalité.
Ah, AppDomain::Unload :
http://msdn.microsoft.com/fr-fr/library/system.appdomain.unl(...)
avec la super phrase :
Dans certains cas, l'appel à Unload provoque une exception CannotUnloadAppDomainException immédiate, par exemple si l'appel est effectué dans un finaliseur.
Tu verras aussi qu'en C++/CLI le problème n'est pas présent, et pourtant c'est le même CLR "mal conçu" :
http://msdn.microsoft.com/fr-fr/library/ms177197.aspx
Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité. J'aime bien le passage:
If your type has a destructor, the compiler will generate a Dispose method that implements IDisposable. If a type authored in Visual C++ with a destructor is consumed from another language, calling IDisposable::Dispose on that type will cause the type's destructor to be called. When consumed from a Visual C++ client, you cannot directly call Dispose; call the destructor instead using the delete operator.
If your type has a finalizer, the compiler will generate a Finalize(void) method that overrides Finalize.