Le faire dans un finalize (donc quand le GC passe) n’est pas toujours une bonne idée. Un exemple simple, imaginez un système qui manque de sockets mais pas de mémoire.

Évidemment, le 1er avril, la prod peut corriger efficacement ce problème en retirant une barrette mémoire :-)

Mac> Puisque nous ne sommes plus le premier avril, je peux tenter une réponse sérieuse :

En C# : Il n’y a pas de destructeur à proprement parler. On utilise la syntaxe C++ d’un destructeur, mais le compilateur traduit ça en un appel au Finalizer. Dispose est juste une méthode comme les autres, sa seule spécificité est qu’elle est reconnue par certaines constructions du langage, et types du framework. On est trop libre d’en faire ce qu’on veut, et d’implémenter IDisposable n’importe comment.

En C++/CLI : Quand on ajoute un destructeur à sa classe, le compilateur rend le type IDisposable, et traduit le destructeur en Dispose. Pour implémenter un finalizer, il faut utiliser une nouvelle syntaxe ( !MaClasseManagée() )

J’avais un très bon lien sur les discussions autour de ce pattern, que je mettrai ici. Mais uniquement si je le retrouve ;-)

 if(!disposed)  
         {  
             // on appelle le garbage collector, et on force la libération de  
             // tous les objets pour être certains de plus référencer des variables  
             // non managées depuis C#  
            for(int i = 0; i < Int32.MaxValue; i++)
            {
                GC.Collect(i);  //On demande à la GC de voir s'il faut libérer chaque adresse du tas, on ne sait jamais
                GC.WaitForPendingFinalizers(); //Ne pas oublier les finaliseurs pendus.
            }
             disposed = Boolean.FileNotFound; // valeur ternaire de boolean, plus safe.
}