Exploiter la symétrie constructeur/ destructeur

Chaque langage a ses particularités, ses avantages et ses inconvénients. Souvent, les désavantages des uns sont les avantages des autres. Le présent document en atteste.

Il existe une vague de langages de programmation relativement récents (en particulier les langages de script comme Python et les langages interprétés comme Java et les divers langages .NET) qui ont en commun un certain nombre de particularités très à la mode:

• ils sont compilés pour une machine virtuelle (la JVM de Java, le CLR de .NET, les diverses machines pour Python, incluant Parrot et celles s'exécutant sur un CLR à code ouvert pour .NET) plutôt que pour un ordinateur concret, ce qui les rend généralement un peu plus lent à l'exécution que des programmes qui seraient compilés pour un ordinateur précis mais accorde une plus grande portabilité de leurs binaires – au contraire de C, C++ ou Pascal, par exemple, où la portabilité se fait au niveau des sources, qu'il faut recompiler sur chaque ordinateur cible;
• ils exploitent au maximum ce qu'on appelle le Late-Binding, ce qui signifie la capacité de découvrir à l'exécution de l'information sur les objets qu'ils manipulent – au contraire, C++ exploite au maximum les liens statiques, cherchant à réduire à sa plus simple expression le travail à faire à l'exécution. On voit d'ailleurs ici une différence philosophique entre les produits voués au développement de produits commerciaux grand public, où la simplicité prime souvent sur l'élégance, la complétude et la vitesse, et un produit (C++) pensé à la base pour permettre aussi du développement de niveau système, et où chaque coût est soupesé et, règle générale, à la discrétion du programmeur;
• pour ce faire, ils tendent à reposer sur une structure d'héritage simple, avec une classe mère de toutes les autres (souvent nommée Object) d'où on peut procéder à des conversions dynamiques de types parent→enfant pouvant être validées à l'exécution car, de par leur parent commun, tous les objets contiennent l'information nécessaire pour procéder à une telle inférence dynamique de types;

• l'abstraction suprème dans ces langages tend à y être unique (la classe mère de toutes les autres), ce qui implique que la plupart des opérations génériques procèdent des références à des instances sur cette classe et nécessitent des conversions explicites de types (des casts);
• avoir une classe unique mère de toutes les autres comporte en retour certains avantages – en particulier, cela permet d'implémenter à même le langage des concepts non banals comme la sérialisation (Java; C#), soit la capacité de transformer un objet en une description neutre susceptible d'être inscrite sur un flux et d'être extraite d'un flux) et la réflexivité (Java; C#) qui est la capacité de représenter le langage dans les termes du langage, à l'aide des objets du langage);
• enfin, une autre particularité de ces langages récents est qu'ils tendent à reposer sur une collecte automatisée d'ordures. La présomption est alors que les programmeurs font trop d'erreurs dans leur gestion de la mémoire allouée dynamiquement (pensez aux opérateurs new/ delete en C++, aux fonctions malloc()/ free() en C), et que le moteur du langage devrait compter en tout temps le nombre de références à chaque objet, et détruire au moment opportun les objets inutilisés.

Ce document se propose de discuter brièvement des avantages et des inconvénients de cette stratégie, et de montrer quelques techniques de programmation exploitant la symétrie constructeur/ destructeur pour montrer que, dans bien des cas, reposer sur une collecte automatique d'ordures seule est une stratégie menant à du code plus sujet aux erreurs.

Comprendre la construction et la destruction

Un objet est une entité active et pleinement responsable de sa propre intégrité. L'encapsulation, renforcée dans la plupart des langages de programmation OO par des qualificateurs de contrôle d'accès (private, public, protected) et par des techniques permettant à un objet de contrôler toute tentative de lecture ou d'écriture d'un de ses attributs en forçant pour ce faire le passage par ses méthodes, permet à un objet de garantir que, dans la mesure où il est a priori dans un état stable, alors il le restera pour la totalité de son existence.

La présomption sur laquelle repose le contrat selon lequel l'objet doit se porter garant de sa propre intégrité est que l'objet sera en contrôle de son état dès le moment où il commencera à exister – dès sa construction.

C'est en partie pourquoi la plupart (tous? Probablement) des langages OO permettent aux objets d'exposer des constructeurs.

// exemple C++ abrégé
class Cercle
{
public:
   // constructeur par défaut
   // (pas de paramètres)
   Cercle();
   // constructeur paramétrique
   Cercle(const float rayon, const Point &centre);
   // constructeur de copie
   Cercle(const Cercle&);
};
void utiliser_cercle(Cercle c);
int main()
{
   Cercle c0, // cercle typique
          c1{2.5f, Point{1,1}}; // cercle choisi
   // utilise le constructeur de copie car c1
   // est passé par valeur
   utiliser_cercle(c1);
}

La mécanique de la copie doit être prise en charge par les objets eux-mêmes dans bien des cas, puisque ce que signifie copier n'est pas toujours clair dans le cas des objets – si un attribut d'un objet est une référence à ou un pointeur vers un autre objet, doit-on copier la référence (le pointeur) ou le référé (le pointé)? Si un objet est une copie d'un autre et si tous deux examinent le même fichier, lequel des deux objets sera responsable de fermer ce fichier?

Un constructeur peut aussi servir à obtenir des ressources pour assister l'objet dans son travail. Évidemment, on parle d'obtenir de la mémoire allouée dynamiquement (souvent avec l'opérateur new), mais aussi d'ouvrir des liens de communication, des connexions à des bases de données, de lancer des threads, d'ouvrir des fichiers, etc.

• De manière symétrique, un destructeur sera la méthode appelée à la fin de la vie d'un objet. Le vocable finalisateur est aussi correct (la finalisation est le problème clé, de toute manière).

Le rôle du destructeur sera de faire en sorte, dans les limites de ses possibilités, que le système soit dans un état aussi stable après la fin de la vie de l'objet qu'il ne l'était avant sa construction. Si l'objet a ouvert des fichiers (à la construction ou ailleurs), alors le destructeur devrait s'assurer que ces fichiers soient fermés. Si l'objet a lancé des threads, alors le destructeur devrait s'assurer que ces threads soient arrêtés, ou du moins faire en sorte que la destruction de l'objet ne mène pas au fonctionnement pour une durée indéterminée de ces threads.

Construction/ destruction manuelle ou automatique?

Les constructeurs et les destructeurs ne sont pas de simples méthodes d'initialisation et de nettoyage. Ce sont des automatismes, des morceaux de la mécanique des langages OO qui assistent les programmes dans leur quête d'intégrité et de simplicité.

int main()
{
   Cercle c0, c1;
   // « défaut »
   c0.init();
   Point p;
   p.init (1,1);
   // « paramétrique »
   c1.init(2.5f, p);
   // utiliser c0, c1
   c1.nettoyer();
   c0.nettoyer();
}

La dualité constructeur/ destructeur est un fondement de l'approche OO, et fait partie des prérequis d'une encapsulation véritable.

C'est à partir de ce constat du caractère fondamental et essentiel de la dualité constructeur/ destructeur que se construira l'argumentaire de ce document : un vrai langage OO doit, pour supporter pleinement l'encapsulation, assurer à la fois la bonne construction et la bonne destruction des objets. La plupart des langages s'en sortent bien avec la construction; les langages à la mode s'en sortent beaucoup moins bien avec la destruction.

public class Z {
   private int indice_;
   private void setIndice(final int n) {
      indice_ = n;
   }
   public int getIndice() {
      return indice_;
   }
   // constructeur paramétrique
   public Z(final int n) {
      setIndice (n);
   }
   // «finalisateur» de Java
   protected void finalize() {
      System.out.print("Mort de " + getIndice());
      try {
         System.in.read();
      } catch (java.io.IOException ioe) {
      }
   }
   public static void main(String [] args) {
      final int NB_Z = 10;
      Z [] tableau = new Z[NB_Z];
      for (int i = 0; i < tableau.length; i++)
         tableau[i] = new Z(i);
      tableau=null;
      System.gc();
   }
}

En insérant un appel explicite à System.gc(), ce qu'on ne devrait pas avoir à faire – si on utilise une collecte automatique d'ordures, après tout, on la veut vraiment automatique – alors un seul des Z verra sa méthode finalize() appelée.

Quelle est l'utilité d'un destructeur qui ne sera pas nécessairement appelé? Et quelle est l'utilité réelle d'une collecte automatique d'ordures si elle n'est pas véritablement faite?

Il faut être honnête : la collecte d'ordures de Java est faite au besoin, l'idée de besoin étant ici liée au constat fait par la JVM que la mémoire se fait rare. Dans la mesure du possible, Java cherche à procéder rapidement et efficacement; s'il peut éviter entièrement de collecter les ordures, alors le moteur de Java le fera.

Que Java ne puisse pas garantir un support complet de l'encapsulation jette une forme de discrédit sur ses prétentions de pureté OO. Un objet en Java peut garantir son intégrité personnelle, mais pas l'intégrité systémique là où il est utilisé. Il n'en a pas les moyens, n'étant pas nécessairement informé de son propre décès.

Pour un cas simple comme celui proposé ci-dessus, l'implémentation de C# est plus stricte du point de vue du support de l'encapsulation que celle de Java.

using System;
namespace z
{
   class Z
   {
      private int indice_;
      private void setIndice(int n)
      {
         indice_ = n;
      }
      public int getIndice()
      {
         return indice_;
      }
      // constructeur paramétrique
      public Z(int n)
      {
         setIndice(n);
      }
      // « destructeur »
      ~Z()
      {
         System.Console.WriteLine("Mort de {0}", getIndice ());
      }
   }
   public class Test
   {
      public static void Main()
      {
         const int NB_Z = 10;
         Z [] Tableau = new Z[NB_Z];
         for (int i = 0; i < Tableau.Length; i++)
            Tableau[i] = new Z(i);
      }
   }
}

On peut croire qu'enrober ces ressources extérieures dans des objets pour les intégrer au système soit une solution au problème de la libération des ressources, mais il se trouve que, si le destructeur n'est pas appelé de manière systématique pour ces objets, alors le problème demeure entier.

Un système OO sérieux a besoin de la dualité constructeur/ destructeur pour implémenter pleinement l'encapsulation, et pour se réaliser en tant que modèle OO.

Collecte automatique d'ordures – qualités et limites

Les moteurs de collecte automatique d'ordures ont leur raison d'être, et ne doivent pas être négligés. Toutefois, ils ne sont pas une solution parfaite et suffisante au problème de la bonne gestion de systèmes OO.

L'une des raisons pour lesquelles on apprécie les moteurs de collecte automatique d'ordures (surtout s'ils assurent l'appel éventuel du destructeur de chaque objet) est qu'ils permettent d'automatiser une solution à un problème qui, sans être complexe outre mesure, est souvent mieux pris en charge par le langage de programmation que par les programmeurs: le problème des objets partageables.

Ce problème est exacerbé par le fait que, dans les langages comme C# et Java qui reposent exclusivement sur l'allocation dynamique de mémoire pour la création d'objets, tous les objets sans exception y sont manipulés de manière indirecte, à travers des références.

public class Z {
   private int valeur_;
   public void setValeur(final int valeur) {
      valeur_ = valeur;
   }
   public int getValeur() {
      return valeur_;
   }
   public Z() {
      System.out.println("Construction");
   }
   public static void main(String [] args) {
      final int NB_Z = 10;
      Z z = new Z();
      Z [] tableau = new Z[NB_Z];
      for (int i = 0; i <tableau.length; i++)
         Tableau[i] = z;
      for (int i = 0; i < tableau.length; i++)
         Tableau[i].setValeur(i);
      for (int i = 0; i < tableau.length; i++)
         System.out.println
            (Tableau[i].getValeur());
   }
}

Dans le cas de la classe Z, par contre, le résultat obtenu peut différer des attentes pour qui n'offre pas une compréhension suffisamment fine de la mécanique de manipulation indirecte des objets.

Le programme en exemple affichera dix fois le chiffre 9, plutôt que les chiffres de 0 à 9 inclusivement, dans l'ordre.

En C++, ce genre de manoeuvre est souvent plus clair dans l'esprit des gens puisque créer automatiquement des objets et les copier est une opération très différente de créer dynamiquement des objets puis les copier. Les manipulations indirectes et directes d'objets n'y sont pas visuellement semblables.

class Z
{
   int valeur_;
public:
   Z(const int val = 0)
      : valeur_(val)
   {
   }
   int getValeur() const noexcept
      { return valeur_; }
   void setValeur(const int valeur)
   {
      valeur_ = valeur;
   }
};

void f()
{
   // constructeur paramétrique
   Z z0(3);
   const int NB_Z = 10;
   // NB_Z appels au constructeur par défaut
   Z tableau[NB_Z];
   //
   // peu importe...
   //
   // fin de la portée («}»). Appel
   // implicite des destructeurs de z0
   // et de chaque Z dans tableau
}

void g()
{
   // constructeur paramétrique
   Z *pz0 = new Z(3);
   const int NB_Z = 10;
   // NB_Z appels au constructeur par défaut
   Z *tableau[NB_Z];
   for (int i = 0; i < NB_Z; i++)
      tableau[i] = new Z;
   //
   // peu importe...
   //
   // fin de la portée («}»). Appel
   // explicite des destructeurs de z0
   // et de chaque Z dans tableau (sinon
   // il y aura perte de mémoire)
   for (int i = 0; i < NB_Z; i++)
      delete tableau[i];
   delete pz0;
}

#include <iostream>
using namespace std;
int main()
{
   const int NB_Z = 10;
   Z *z = new Z;
   Z *Tableau[NB_Z];
   for (int i = 0; i < NB_Z; i++)
      Tableau[i] = z;
   // ceci est suspect...
   for (int i = 0; i < NB_Z; i++)
      Tableau[i].setValeur(i);
   for (int i = 0; i < NB_Z; i++)
      cout << Tableau[i].getValeur()
           << endl;
   delete z;
}

int main()
{
   const int NB_Z = 10;
   Z *z = new Z;
   Z *tableau[NB_Z];
   for (int i = 0; i < NB_Z; i++)
      tableau[i] = z;
   // ...
   for (int i = 0; i < NB_Z; i++)
      delete tableau[i]; // Ow! Mauvais!!!
}

Évidemment, cela pose des questions importantes, comme celle du programme C# ci-dessous.

using System;
namespace z
{
   class Z
   {
      private Z voisin_;
      private int indice_;
      public void setVoisin(Z Voisin)
      {
         voisin_ = Voisin;
      }
      private void setIndice(int n)
      {
         indice_ = n;
      }
      public int getIndice()
      {
         return indice_;
      }
      public Z(int n)
      {
         setIndice(n);
      }
      ~Z()
      {
         System.Console.WriteLine("Mort de {0}, voisin de {1}" getIndice(), voisin_.getIndice());
      }
   }
   public class Test
   {
      public static void Main()
      {
         const int NB_Z = 10;
         Z [] t = new Z[NB_Z];
         for (int i = 0; i < t.Length; i++)
            t[i] = new Z(i);
         for (int i = 0; i < t.Length; i++)
            t[i].setVoisin (t[(i+1)%t.Length]);
      }
   }
}

Le même problème surviendra si un objet se réfère à lui-même (si une instance de Z a elle-même pour voisin) :

Z z = new Z(24);
z.setVoisin(z);

Encore une fois, le moteur de collecte d'ordures de C# tranche le noeud gordien de manière brutale mais efficace. L'objet z sera éventuellement détruit, mais seulement à la prochaine collecte d'ordures, qu'il reste ou non une référence (une autoréférence!) dans sa direction.

Les langages récents intègrent à peu près tous un modèle de multiprogrammation. Cela implique qu'il est fréquent dans ces langages que des programmes créent des objets qui seront utilisés de manière concurrente par plusieurs séquences de code.

Quand un objet alloué dynamiquement est partagé par plusieurs threads, la question naturelle à poser est lequel des threads sera responsable de détruire cet objet? Et la réponse ne peut pas toujours clairement être celui qui a créé l'objet, puisque les threads meurent dans un ordre qui leur est propre et qu'il est possible que le thread ayant créé un objet ne soit pas le dernier thread à utiliser l'objet en question.

En soi, la question de l'euthanasie d'un objet est subjective. Il faut, pour savoir vraiment quand détruire un objet, compter en tout temps le nombre de références vers cet objet, et ne le détruire que lorsque le nombre de références est nul.

Compter les références vers chaque objet est une tâche dont un moteur OO s'acquittera en général très bien, mais seulement dans l'optique où ce moteur connaît les tenants et aboutissants de chaque objet – donc dans la mesure où tous les objets utilisés, sans exception, font partie intégrante du langage. C'est là un problème que Java et .NET ont tous deux rencontré, et pour lequel il n'existe aucune solution parfaite. Les solutions possibles varient plus en esthétisme qu'en qualité.

Évidemment, quand les objets en interaction dans un système proviennent de plusieurs machines virtuelles, sur une seule ou plusieurs plates-formes et rédigés dans un seul ou plusieurs langages de programmation, il devient difficile (et pour le moment impossible) de compter sur une véritable collecte automatique d'ordures efficace et répartie. Un exemple expliquant comment on pourrait implémenter manuellement une telle mécanique sera exposée dans Partageabilité collaborative en l'absence de collecte automatisée d'ordures, plus bas, mais une telle stratégie demandera l'usage d'un langage permettant à un programme de gérer lui-même le moment de la destruction de ses objets.

Paire construction/ destruction automatique

Il y a plus d'avantages de que d'inconvénients à la construction/ destruction automatique, surtout dans la mesure où la destruction automatique se fait dès que l'objet alloué automatiquement quitte la portée dans laquelle il a été déclaré. Pour que Java et C# puissent exploiter les techniques qui suivent, il leur faudrait, au choix :

• permettre la création automatique d'objets, non soumise à la collecte automatique d'ordures, ce qui compliquerait probablement le modèle de gestion de mémoire de ces langages; ou
• permettre de marquer certains objet pour collecte immédiate, ce qui semble plus simple à faire en C# (grâce aux métadonnées et aux attributs dont on peut coiffer certains éléments de code dans ce langage) qu'en Java.

Que permet l'exploitation de la symétrie construction/ destruction automatique? Énormément de techniques de programmation très simples, très sécuritaires et très efficaces. En voici quelques exemples.

Gestion propre des fichiers

Examinez les programmes Java et C++ ci-dessous. Les deux procèdent à une copie d'un fichier texte nommé "In.txt" dans un aute fichier texte nommé "Out.txt".

import java.io;
public class CopieFichiers {
   public static void main(String [] args) {
      FileReader fr = null;
      FileWriter fw = null;
      try {
         fr = new FileReader(new File("In.txt"));
         fw = new FileWriter(new File("Out.txt"));
      } catch (FileNotFoundException fnfe) {
         // ...
      } catch (IOException ioe) {
         // ...
      }
      BufferedReader br = new BufferedReader(fr);
      BufferedWriter bw = new BufferedWriter(fw);
      try {
         String s = br.readLine();
         while (s != null) {
            bw.write(s);
            bw.newLine();
            s = br.readLine();
         }
         bw.flush();
      }
      catch (IOException ioe) {
      } finally {
         br.close();
         bw.close();
      }
   }
}

#include <fstream>
#include <string>
int main()
{
   using namespace std;
   ifstream ifs{"In.txt"};
   ofstream ofs{"Out.txt"};
   string s;
   while (getline(ifs, s))
      ofs << s << endl;
}

Le programme C++ pourrait être plus court encore (voir ceci pour des exemples), mais cette version nous suffira pour les fins de l'explication. Mettons de côté la différence de complexité entre les deux implémentations, dûe à beaucoup de facteurs mais surtout à la manière de gérer les exceptions des deux langages (obligation en Java, option en C++, et fait que la lecture en C++ retourne une référence sur le flux duquel elle fut faite, et que ce flux peut être testé comme un booléen – faux lors d'une erreur en lecture).

Le point qu'il faudrait remarquer ici est que dans la version Java, la seule manière de garantir la bonne fermeture des flux d'entrée/ sortie sur les fichiers est d'appeler explicitement la méthode close() de chacun. Ici, ces appels sont insérés dans une clause finally pour que nous soyons assurés qu'ils auront lieu, peu importe qu'une exception soit levée ou non dans le bloc try.

Le fait que C++ appelle implicitement les destructeurs des objets créés automatiquement lorsque ceux-ci atteignent la fin de leur portée permet de responsabiliser chaque flux quant à sa propre fermeture, ce qui permet un support beaucoup plus complet de l'encapsulation.

Avantage non négligeable : les destructeurs d'une variable automatique sont appelés peu importe la circonstance selon laquelle la fin de la portée est atteinte: sortie brusque (return, exit(), throw) ou naturelle (atteinte de la fin du bloc), peu importe. Ainsi, le concept de finally dans la gestion des exceptions est essentiellement superflu en C++.

Automatisation de configurations

Imaginons un programme ayant besoin de charger une ressources externe au démarrage et de décharger cette ressource à la fermeture (une bibliothèque à liens dynamiques, une connexion à une BD, un autre programme, peu importe).

public class ChargementQuasiAutomatique {
   private class Chargeur {
      public void charger() {
         // code pour charger la ressource
      }
      public void décharger() {
         // code pour décharger la ressource
      }
   }
   public static void main(String [] args) {
     Chargeur c = new Chargeur();
     c.charger();
     // reste du programme. Si des exceptions
     // sont possibles, il faut s'assurer de
     // les attraper et de faire en sorte que
     // l'appel à décharger() ci-dessous soit
     // fait, peu importe ce qui arrivera
     c.décharger();
   }
}

struct Chargeur
{
   Chargeur()
   {
      // code pour charger la ressource
   }
   ~Chargeur() noexcept
   {
      // code pour décharger la ressource
   }
};
int main()
{
   Chargeur c;
   // reste du programme. Rien à faire de
   // spécial, puisque le constructeur du
   // Chargeur a déjà chargé la ressource
   // et puisque, peu importe la manière
   // dont le programme se terminera, le
   // destructeur de cet objet déchargera
   // la ressource
}

Ici, le code Java est plutôt fragile : le programme principal doit commencer son exécution par le chargement explicite de la ressource et doit s'assurer par lui-même du déchargement de la ressource, alors qu'en C++, le déchargement se produira automatiquement de par la destruction du Chargeur, quoiqu'il advienne..

Classes de capture

Il existe un patron fort intéressant pour automatiser et solidifier des opérations a priori délicates et pouvant laisser un système dans un état instable. Imaginons par exemple un bloc de code dans une méthode pour lequel une synchronisation est requise. Pour simplifier la démonstration, nous procéderons à la saisie de mesures de temps d'exécution pour une méthode.

public class Mesures {
   private class Mesure {
      private class Créateur {
         public Créateur () {
            // Créer un journal vide
         }
      }
      // instanciation du singleton
      static Créateur singleton = new Créateur();
      private String nom_méthode_;
      Mesure(String nom_méthode) {
         nom_méthode_ = nom_méthode;
      }
      public void début() {
         // saisir le temps courant
      }
      public void fin() {
         // saisir le temps courant, faire
         // la différence avec le temps au
         // début et insérer cette différence
         // dans le journal avec le  nom de
         // la méthode. Bien prendre soin de
         // fermer manuellement le journal!
      }
   }
   void àMesurer() {
      Mesure m = new Mesure("àMesurer()");
      m.début();
      // opérations dont on veut mesurer
      // le temps d'exécution. Si une
      // exception ou un autre problème
      // devait survenir, il faudrait que
      // l'appel à m.fin() soit fait à la
      // pièce et dans chaque cas.
      m.fin();
   }
   public static void main(String [] args) {
      // Batterie de tests
      final int NB_TESTS = 1000;
      for (int i = 0; i < NB_TESTS; i++) {
         à_mesurer();
      }
   }
}

//
// Mesure.h
//
#include <fstream>
#include <chrono>
#include <string>
using namespace std;
using namespace std::chrono;
class Mesure
{
   struct Createur
   {
      Createur()
      {
         // Créer un journal vide
         ofstream ("Log.txt");
      }
   };
   static Createur singleton;
   string nom_methode_;
   system_clock::time_point avant_;
public:
   Mesure(const string &nom_methode)
      : nom_methode_(nom_methode)
   {
      avant_ = system_clock::now();
   }
   ~Mesure()
   {
      auto ecoule = system_clock::now() - avant_;
      ofstream log{"Log.txt", std::ios::app};
      log << duration_cast<milliseconds>(ecoule).count() << endl;
   }
};

//
// Mesure.cpp
//
#include "Mesure.h"

// définition du singleton
Mesure::Createur Mesure::singleton;

//
// Programme en soi
//

void a_mesurer()
{
   Mesure m("a_mesurer()");
   // opérations dont on veut mesurer
   // le temps d'exécution. Le fichier
   // journal sera correctement fermé
   // quoiqu'il arrive.
}

int main()
{
   // Batterie de tests
   const int NTESTS = 1000;
   for (int i = 0; i < NTESTS; ++i)
      a_mesurer();
}

Ici encore, le code Java semble plus court (c'est une illusion dûe aux commentaires, car il est beaucoup plus long!), mais il est de loin plus fragile et plus complexe à gérer. Deux appels à la méthode fin() d'une même instance de Mesure peut corrompre le journal; une erreur manuelle dans le code (oublier de fermer le journal, oublier d'appeler manuellement fin() lors d'une exception, etc.) peut entraîner une perte d'information.

En C++, l'existence même d'une instance automatique de Mesure garantit non seulement l'intégrité de l'objet, mais aussi la qualité de la mesure en tant que telle. Il est impossible d'appeler manuellement et incorrectement la méthode d'une Mesure servant à inscrire la mesure au journal, cette méthode étant le destructeur de l'objet.

Durée de vie des objets et systèmes répartis

Les systèmes répartis constituent un autre animal informatique qui se prête mal à une collecte automatique d'ordures. Les références vers un objet donné pouvant venir de plusieurs threads/ de plusieurs processus/ de plusieurs ordinateurs distincts, les moteurs de collecte automatique d'ordures tendent à offrir peu ou pas de garanties pour des objets jouant un rôle de serveur pour des objets clients pouvant être répartis un peu partout et ne se trouvant pas sous la gouverne de la machine virtuelle du serveur.

Formalisme collaboratif (p. ex. : COM)

Le modèle COM, vieillissant mais encore utilisé, exige de tous les composants (disons tous les objets, pour simplifier, même si en réalité la chose est plus complexe) du modèle qu'ils respectent une interface spécifique (IUnknown) et donc qu'ils en exposent toutes les méthodes. Parmi celles-ci, ont trouve une paire de méthodes pour permettre le compte des références sur un objet donné, soit une méthode, AddRef(), pour informer un objet qu'il vient de se gagner un client (qu'un nouveau pointeur mène maintenant vers lui) et une autre, Release(), pour informer l'objet qu'un de ses clients vient de le quitter.

L'objet étant le seul à pouvoir compter ses propres clients, il doit aussi être tenu responsable de sa propre destruction lorsque le dernier de ses clients se sera déconnecté. Ce modèle se prête donc mal à une collaboration avec un moteur de collecte automatique d'ordures.

Ce formalisme fonctionne parfaitement dans la mesure où la connexion est stable entre le serveur et ses clients (ou dans la mesure où le moteur d'interopérabilité situé entre le serveur et ses clients génère par lui-même le bon nombre d'appels à Release() sur le serveur si sa connexion avec un client donné est brisée), et dans la mesure où les clients gèrent rigoureusement les appels aux deux méthodes en question.

Formalisme par bail et mécène (p. ex. : .NET, Java)

Les modèles de .NET et de Java ont une granularité plus grossière, moins précise, mais sont aussi moins lourds à supporter pour le moteur d'interopérabilité.

Chaque composant dans un système réparti se fait offrir un bail d'une certaine durée. Chaque appel à une méthode de l'objet réinitialisera le bail, ce qui fait qu'un objet sollicité fréquemment demeurera en mémoire. Une fois que le bail d'un objet aura expiré, cet objet sera sujet à être ramassé par le moteur de collecte automatique d'ordures. Au besoin, on pourra attribuer un mécène à chaque objet, soit un objet dont le rôle sera d'en autoriser (ou non) la collecte.

Dans ce modèle, l'objet n'a pas de contrôle sur sa propre durée de vie, et ne restera en mémoire que s'il est utilisé régulièrement (ou si l'on y force). Il se prête donc bien aux collectes automatiques d'ordures.

Partageabilité collaborative en l'absence de collecte automatisée d'ordures

La possibilité de partager des objets est un des aspects de l'informatique contemporaine qui rend les mécaniques d'utilisation indirecte (via pointeurs ou références) et les collectes automatiques d'ordures très alléchantes.

En effet, le problème des objets partagés est que tout client d'un tel objet (tout objet ayant un pointeur dans sa direction) est susceptible, en tout temps, d'être le dernier client. En même temps, il est pratiquement impossible (du moins si on veut rédiger du code propre et respectueux du principe d'encapsulation) de demander au dernier client d'un objet donné de vérifier qu'il en est le dernier puis, si c'est le cas, de détruire l'objet partagé. De plus, en situation multiprogrammée, il faudrait que la paire d'opérations {si je suis le dernier client, alors détruire l'objet}soit atomique, pour éviter qu'un nouveau client ne s'ajoute entre le moment du test et celui de la destruction.

Dans un modèle sans collecte automatique d'ordures, le moment où le dernier client cesse de pointer vers un objet donné est celui où cet objet est irrémédiablement perdu. Si plus personne ne mène vers lui, alors il ne seras jamais détruit. Les moteurs de collecte automatique d'ordures, eux, tiennent un compte se voulant rigoureux du nombre de clients de chaque objet, et procèdent régulièrement à une phase de nettoyage des objets vers lesquels plus personne ne mène – ce qui rend ceci possible est que le moteur de collecte d'ordures est le seul client de chaque objet pour lequel la comptabilité du nombre de références d'entre pas en considération.

L'encapsulation suggère que, si aucun moteur ne prend en charge automatiquement la destruction des objets orphelins, il faut que les objets sur le point de devenir orphelins soient responsables de leur propre destruction. Conséquemment, ces objets doivent être informés de chaque ajout d'un pointeur et de chaque retrait d'un pointeur dans leur direction.

On peut y arriver simplement par héritage (idéalement par héritage multiple), comme le montre l'exemple suivant.

#include <windows.h>
#include "GenerateurStochastique.h"

class Partageable
{
   long cptref_;
public:
   Partageable()
      : cptref_{1}
   {
   }
   virtual ~Partageable() = default;
   long AddRef() noexcept
      { return ++cptref_; }
   long Release() noexcept
   {
      if (--cptref_)
         return cptref_;
      delete this;
      return 0L;
   }
};

unsigned long __stdcall Th(void *p)
{
   auto &part =
      *reinterpret_cast<Partageable*>(p);
   auto &gs = GenerateurStochastique::get();
   while(gs.Piger(1,100)!=50)
      Sleep(20);
   part.Release();
   return 0L;
}

class CreerThread
{
   Partageable *p_;
public:
   CreerThread(Partageable *p)
      : p_{p}
   {
      p_->AddRef();
   }
   CreerThread(CreerThread &org)
      : p_{org.p_}
   {
      p_->AddRef();
   }
   ~CreerThread() noexcept
      { p_->Release(); }
   //
   // Le code qui suit n'est pas sain dans
   // sa gestion des erreurs, mais c'est un
   // exemple sans prétention
   //
   HANDLE operator()() const
   {
      p_->AddRef();
      return CreateThread(0, 0, Th, p_, 0, 0);
   }
};
void FermerThread(const HANDLE hTh)
   { CloseHandle(hTh); }

class Truc
   : public Partageable
{
   // peu importe
};

#include <algorithm>
using namespace std;
int main()
{
   const int N = 10;
   HANDLE h[N] = { 0 };
   Partageable *p = new Truc;
   generate(begin(h), end(h), CreerThread(p));
   p->Release();
   WaitForMultipleObjects(begin(h), end(h), TRUE, INFINITE);
   for_each(begin(h), end(h), FermerThread);
}

Automatiser le mécanisme

class Autorelacheur
{
   Partageable *p_;
public:
   Autorelacheur(Partageable *p)
      : p_(p)
   {
      p_->AddRef();
   }
   ~Autorelacheur() noexcept
      { p_->Release(); }
};
void f(Partageable *p)
{
   Autorelacheur ar(p);
   // reste de la fonction... f() sera cliente de p jusqu'à
   // ce qu'elle ait complété son exécution. La destruction de
   // ar entraînera le relâchement du Partageable nommé p
}

Ainsi, une fonction (comme f()) ayant besoin d'un Partageable pour son exécution peut déclarer localement une instance de Autorelacheur (qui doit être nommée, comme dans le cas de ar ici).

Ceci permet une automatisation simple, rapide et efficace de la mécanique symétrique d'obtention et de relâchement d'un Partageable.

class X // classe très simple
{
   int val_;
public:
   X(int val)
      : val_{val}
   {
   }
   X& operator ++()
   {
      ++val_;
      return *this;
   }
};
#include <memory>
void f()
{
   using std::unique_ptr;
   unique_ptr<X> p{new X{3}};
   X* q = new X(4);
   ++(*p); // on utilise un unique_ptr comme un pointeur normal
   ++(*q);
   // ...
   unique_ptr<x> r = p; // ceci désassocie p; seul r pointe maintenant
                        // sur l'objet créé par new X(3) plus haut
   *r = 8; // ok
   *p = 3; // ILLÉGAL
   delete q; // destruction explicite du pointeur q
} // destruction implicite de l'autopointeur r; p, lui, est déjà nul

Pour le partage des pointés, il y a mieux encore, soit la classe shared_ptr. De manière générale, les pointeurs intelligents sont préférables à une approche intrusive comme celle utilisée ci-dessus, qui repose sur l'héritage et force ainsi l'insertion d'une dépendance supplémentaire envers un parent.

En pratique, en C++, on préfère de loin l'approche non-intrusive passant par des pointeurs intelligents à une approche intrusive qui impose un parent tel que Partageable. Les approches non-intrusives sont plus flexibles, s'appliquent à une plus vaste gamme de types (incluant des types primitifs), et réduisent par conséquent le couplage dans le code.

La collecte d'ordures sous .NET, plus en détail

Ce qui suit provient en majeure partie d'un courriel envoyé par Joël Collin, qui me faisait remarquer que le code C# présenté à l'époque comme fonctionnel mais suspect était en fait défectueux, mais ne plantait qu'après une longue période d'utilisation pour des raisons circonstancielles. Joël utiliseait à l'époque C# de manière professionnelle et ses remarques sont tout à fait pertinentes.

Je me suis permis des annotations (à droite, dans des encadrés) et quelques retouches linguistiques, mais son propos reste intact pour l'essentiel.

Tout d'abord, les clarifications :

• la collecte d'ordures (de .NET) est basée sur un système de promotion des objets. Au départ, tous sont à la génération 0. Lorsqu'une collecte est effectuée, si un objet voit son compteur de références afficher 1 et plus, il est automatiquement promu à la génération suivante jusqu'à ce qu'il atteigne la génération 2. En réalité, les variables utilisées localement dans une méthode ne sont jamais promues alors que les membres d'un objet vivant tout au long de l'exécution d'un programme (par exemple, un singleton) seront vraisemblablement promus jusqu'à la génération 2;
• la collecte d'ordures de la génération 0 se fait relativement souvent alors que la collecte de génération 2 ne se fait que rarement. Ceci s'explique par le fait que les objets en génération 2 sont normalement des objets ayant une longue durée de vie. Si une majorité de nos objets se retrouvent systématiquement dans la génération 2, il est probable que le principe de localité soit bafoué et que le design soit à revoir;
• une fois qu'un objet est ramassé par la collecte d'ordures, le CLR vérifie s'il doit appeler son « finalisateur » (désolé pour le néologisme, j'ignore comment mieux traduire Finalizer). Le finalisateur est ce que tu appelles à tort le destructeur: en réalité, il ne détruit rien. Si le finalisateur doit être appelé, ce travail est ajouté dans la file du finalisateur;
• une fois que le finalisateur a été sollicité, on ne peut plus garantir l'état des objets auxquels il a été appliqué. Le bloc de mémoire dans lequel se trouvait l'objet est peut-être disparu.

Ces clarifications expliquent ta chance. En effet, je suis surpris que tu n'aies jamais eu d'exceptions. Si tu augmentais un peu la valeur de ta constante Z (pour les besoins de la cause à 1000000) et que tu exécutais de nouveau ton programme, tu verrais qu'en réalité, tous tes finalisateurs ne sont pas appelés. J'ai tenté l'expérience sur mon poste et le processus s'est terminé à la ligne Mort de 994140, voisin de 994141 après avoir finalisé moins de 6000 objets. Pire encore, si tu étais vraiment malchanceux, la classe statique Console pourrait s'être fait collecter au passage et Console.WriteLine te lancerait une exception.

Maintenant, quelle est la solution? En fait, devant ce manque flagrant de déterminisme, Microsoft a offert à la communauté un patron de disposition des objets pris en charge. On voudra en effet parfois libérer des quantités importantes de mémoire, bien que prises en charge, quand bon nous semble. On ne sait jamais, un objet pourrait contrôler une ressource matérielle lorsqu'aucun client n'en veut, on voudrait qu'il se ferme immédiatement (sans attendre la collecte) [oui, c'est trop précis pour ne pas être un cas vécu ].

Le patron de disposition est relativement simple. On implémente l'interface IDisposable qui offre une méthode dont la signature est la suivante: void Dispose().

De plus, on ajoutera une méthode protégée ayant la signature suivante: protected void Dispose(bool disposing). À l'intérieur de la méthode Dispose(), on fera un appel à Dispose(true). À l'intérieur du finalisateur, on fera Dispose(false).

On force donc les clients à appeler Dispose() explicitement. Pas d'appel automatique comme C++ fait avec son destructeur.

Scénario 1

L'implémentation de protected void Dispose(bool disposing) aura donc cette allure :

protected void Dispose(bool disposing)
{
   if (disposing)
   {
      // On fait le ménage de nos objets pris en charge
   }
}

Tout de suite, je suis certain que tu te dis : Ok, mais à quoi cela sert-il de mettre un appel à Dispose(false) dans le finalisateur?

À ça je répondrai : À quoi le finalisateur sert-il? En effet, on implémente un finalisateur seulement quand on désire se débarasser d'objets non pris en charge (une interface COM à laquelle nous avons fait un AddRef(), par exemple, et qui va rester en vie toujours si on ne fait pas de Release()).

Scénario 2

protected void Dispose(bool disposing)
{
   if (disposing)
   {
      // On fait le ménage de nos objets pris en charge
   }
   // On fait le ménage des objets non pris en charge
}

Bon, encore un commentaire? Laisse-moi deviner... C'est con ton truc, on va faire nous-même le ménage de notre objet et ensuite on va se refaire nettoyer. Bonne remarque. J'allais justement en parler! Pour éviter que le finalisateur soit appelé après que nous ayons procédé au nettoyage de façon déterministe, il faut appeler System.GC.SuppressFinalize(this) à la fin de notre méthode Dispose(bool diposing). Ceci aura pour effet d'informer le moteur de collecte d'ordures qu'il n'y a rien à finaliser. Côté performance, ça vaut la peine de le faire.

Scénario 3

Si on n'a pas d'objets non pris en charge dans la classe, on peut se permettre de ne pas implémenter le finalisateur du tout. Dans ce cas, on peut quand même garder la structure du patron Dispose().

Si tout est géré dans la classe et si les objets n'occupent pas beaucoup d'espace, mieux vaut laisser le moteur de collecte d'ordures faire le boulot. Il est ajusté pour faire le travail dans les pires conditions et le fait probablement mieux que quiconque. Aussi, il y a deux règles fondamentales : la première est que nous n'appelons jamais explicitement GC.Collect() et la deuxième est que nous respectons rigoureusement la première règle. De toute manière, les appels à GC.Collect() ne garantissent en rien la collecte d'un objet.

Revenons donc à ton exemple. J'ai pris soin de le modifier pour qu'il respecte les règles du jeu. Normalement, dans cet exemple, le patron de disposition ne sert à rien. Quand il aura besoin d'espace, le moteur de collecte d'ordures enlèvera tes 10 entiers et ça finira là. Évidemment, je comprends qu'il s'agit d'un exemple pédagogique alors considérons l'appel à Console.WriteLine() comme un appel critique qui doit absolument être fait (pour pimenter le tout, on aurait pu ajouter des références à des flux qui ont ouvert un fichier mais ne l'ont pas encore fermé – mais il est déjà tard et je travaille demain).

Conclusion

Alors quelles conclusions devrait-on tirer? Premièrement, que ce n'est pas parce qu'il y a un moteur de collecte d'ordures qu'on peut se permettre de gaspiller la mémoire. La mémoire est une ressource qu'on devrait bien gérer dans tout bon programme. Un moteur de collecte d'ordures est habituellement très gourmand: il allouera jusqu'à saturation et allouera par grosses tranches.

On peut aussi dire que le moteur de collecte d'ordures de .NET est plutôt efficace quand on l'utilise de la bonne manière. Le patron de disposition est excellent pour ajouter du déterminisme et on ne devrait se servir du finalisateur que dans des cas. Avec un bon design, on contrôle la création et la disposition des objets en tout temps.

On peut aussi dire qu'avec .NET, tout est facile... jusqu'à temps que ça devienne difficile. Alors, les enquêtes prennent des proportions gargantuesques (comme ce message d'ailleurs, que je souhaite instructif).

À l'endroit où je travaille, nous développons depuis deux ans un logiciel en C# (qui contient beaucoup classes et fait beaucoup d'interopérabilité avec COM et d'autres ressources non prises en charge – fichiers, objets GDI ou autres) et nous n'avons pas un seul finalisateur qui entre en jeu. Ils sont implémentés, certes, dans certaines classes spécifiques – pas plus de cinq ou six – mais ils ne contiennent que des assertions qui n'ont jamais été rejointes. Étonnamment, nous n'avons ni fuite de mémoire, ni fuite de ressources.

namespace z
{
   class Z : IDisposable
   {
      private Z voisin_;
      private int indice_;
      public void setVoisin(Z voisin)
      {
         voisin_ = voisin;
      }
      private void setIndice(int n)
      {
         indice_ = n;
      }
      public int getIndice()
      {
         return indice_;
      }
      public Z(int n)
      {
         setIndice(n);
      }
      ~Z()
      {
         this.Dispose(false);
      }
#region IDisposable Members
      public void Dispose()
      {
         this.Dispose(true);
      }
#endregion
      protected void Dispose(bool disposing)
      {
         if (disposing)
         {
            System.Console.WriteLine("Mort de {0}, voisin de {1}", getIndice(), voisin_.getIndice());
         }
         GC.SuppressFinalize(this);
      }
   }
   public class Test
   {
      public static void Main()
      {
         const int NB_Z = 1000000;
         Z[] t = new Z[NB_Z];
         for (int i = 0; i < t.Length; i++)
            t[i] = new Z(i);
         for (int i = 0; i < t.Length; i++)
            t[i].setVoisin(t[(i + 1) % t.Length]);
         for (int i = 0; i < t.Length; i++)
            t[i].Dispose();
      }
   }
}

Stabiliser la libération de ressources en C# – le mot clé using

Un moteur de collecte automatique d'ordures a de bons côtés mais est aussi très limitatif pour ce qui est de l'implémentation de l'encapsulation.

En effet, le moment de la destruction des objets devenant imprévisible (ou devant être pris en charge manuellement), il faut souvent réaliser explicitement des opérations (comme fermer un fichier ou un socket) qui devraient, si l'encapsulation était pleine et entière, être faites de manière automatique et implicite par les objets qui les représentent. Cela force le code client d'un objet à faire manuellement des opérations qui devraient être du ressort de cet objet.

using System;
namespace Z
{
   public class Test
   {
      private void AccèsFichier()
      {
         //
         // L'appel à la méthode Close() du
         // StreamWriter doit être faite de
         // manière explicite, sinon on ne
         // peut savoir combien de temps le
         // flux restera ouvert (et, de manière
         // accidentelle, on peut en venir à
         // manquer de ressources
         //
         System.IO.StreamWriter sw = System.IO.File.CreateText("z.txt");
         sw.WriteLine("Coucou");
         sw.Close();
      }
      [STAThread]
      static void Main(string [] args)
      {
         Test pTest = new Test();
         pTest.AccèsFichier();
      }
   }
}

#include <fstream>
void AccesFichier()
{
   using namespace std;
   //
   // Pas d'appel explicite à la méthode
   // ofs.close(); le destructeur de
   // l'objet est responsable de libérer
   // les ressources sous sa gouverne
   //
   ofstream ofs{"z.txt"};
   ofs << "Coucou" << endl;
}
int main()
{
   AccesFichier();
}

Ce type de problème est exacerbé lorsque le code se complique (dans les méthodes où il y a plus d'un point de sortie, à cause de traitement d'erreur ou de levées d'exceptions), du fait que les appels explicites à la libération des ressources se multiplient rapidement.

Le langage C# offre toutefois un moyen de pallier ce problème, en permettant d'utiliser le mot clé using autrement que dans le cas où un espace nommé doit être accédé implicitement. Un bloc peut être préfixé par using(expr) où expr est une expression dont le type doit être au moins IDisposable. Le langage prend alors en charge l'appel implicite à la méthode Dispose de l'objet décrit par expr à la fin du bloc.

Comme c'est souvent le cas avec C#, on s'en sort par un ajout au langage plutôt que par nos propres moyens, mais au moins il y a une porte de sortie pour rédiger du code un peu moins fragile.

namespace Z
{
   public class Test
   {
      private void AccèsFichier()
      {
         using(StreamWriter sw = File.CreateText(path))
         {
            sw.WriteLine("Hello");
            sw.WriteLine("And");
            sw.WriteLine("Welcome");
         } // l'appel à sw.Dispose() est implicite,
           // qu'il y ait ou non levée d'exception
      }
      [STAThread]
      static void Main(string [] args)
      {
         Test pTest = new Test();
         pTest.AccèsFichier();
      }
   }
}

Un exemple de code C# profitant de ce mot clé pour générer une trace simple (message avant une tâche, message après cette tâche) suit. Le code C++ de même fonctionnalité est proposé à titre comparatif.

using System;
namespace DémoRAII
{
   class Test
   {
      private class AutoTrace : IDisposable
      {
         string nom_bloc_;
         public AutoTrace(string nomBloc)
         {
            nom_bloc_ = nomBloc;
            System.Console.WriteLine("Début de la trace de {0}", GetNomBloc());
         }
         string GetNomBloc()
         {
            return nom_bloc_;
         }
         public void Dispose()
         {
            System.Console.WriteLine("Fin de la trace de {0}", GetNomBloc());
         }
      }
      private void f()
      {
         using(AutoTrace at = new AutoTrace("f()"))
         {
            // un travail quelconque
         } // Dispose() appelé ici
      }
      static void Main(string[] args)
      {
         Test pTest = new Test();
         pTest.f();
      }
   }
}

#include <iostream>
#include <string>
using namespace std;
class AutoTrace
{
   string nom_bloc_;
public:
   AutoTrace(const string &nomBloc)
      : nom_bloc_(nomBloc)
   {
      cout << "Début de la trace de "
           << nom_bloc() << endl;
   }
   string nom_bloc() const
      { return nom_bloc_; }
   ~AutoTrace() noexcept
   {
      cout << "Fin de la trace de "
           << nom_bloc() << endl;
   }
};
void f()
{
   AutoTrace at("f()");
   // un travail quelconque
} // destructeur de at appelé ici
int main()
{
   f();
}

Java a suivi la même voie et, depuis la version 7 de ce langage, les blocs Try-With sont supportés. Là où C# utilise IDisposable et Dispose() pour gérer la libération des ressources, Java utilise Closeable et close(). Pour le reste, c'est blanc-bonnet, bonnet blanc.

Remarques quant aux coûts reliés à l'emploi de using

C'est utile d'insérer des opérations dans un bloc using si tu crains que les développeurs qui travaillent avec toi oublient d'appeler Dispose (remarque de Patrice : l'idée est aussi de simplifier les cas où de multiples points de sortie – exceptions incluses, y compris par des méthodes qui y sont appelées – alourdiraient une méthode au point de rendre difficile son entretien; l'incompétence est un facteur, mais le problème est plus profond que ça). Mais il faut aussi se demander combien ça coûte.

using(Stream s = new FileStream("C:\\bidon.txt"))
{
   // ...
}

... mais à l'exécution, le code pourrait s'exécuter sur un disque C: qui est plein et une exception serait levée. Sans trop de surprise, le moteur va appeler s.Dispose() même si il y a une exception (le contraire serait troublant). Comment fait-il? Lors de la compilation, il va tout simplement remplacer le bloc using par un bloc try/ finally .

Tu sais qu'il y a un surdébit (Overhead?) important lorsqu'on utilise ces machins. Avec .NET, par exemple, toutes les méthodes qui utilisent le mot-clé throw dans leur définition ne sont pas inlinées... Pour s'en convaincre, regardons un petit bout de programme anodin. La classe MaClasse a une propriété en lecture seulement MaChaine. Pour une raison éducative, on veut s'assurer que la variable privée chaine_ soit vide quand on Dispose() l'instance de MaClasse.

using System;
namespace MonNamespace
{
  static class Program
  {
    [STAThread]
    static void Main()
    {
      using (MaClasse maClasse = new MaClasse("maChaine!"))
      {
         Console.WriteLine(maClasse.MaChaine);
      }
    }
    private class MaClasse : IDisposable
    {
      private string chaine_ = string.Empty;
      public MaClasse(string maChaine)
      {
         chaine_ = maChaine;
      }
      public string MaChaine
      {
         get
         {
            return chaine_;
         }
      }
      public void Dispose()
      {
         chaine_ = string.Empty;
      }
    }
  }
}

On compile et on utilise ildasm (remarque de Patrice : très utile, ça. Je m'en sers souvent, surtout pour régler des problèmes d'interopérabilité entre .NET et le monde natif. C'est un bel outil, simple et bien fait) qui vient avec le .NET Framework pour voir de quoi a l'air le code en langage intermédiaire (ayant compilé en Debug, c'était rempli de nop à cause de certains commentaires; j'ai pris la liberté de les enlever) :

.method private hidebysig static void  Main() cil managed
{
  .entrypoint
  .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
  // Code size       46 (0x2e)
  .maxstack  2
  .locals init ([0] class MonNamespace.Program/MaClasse maClasse,
           [1] bool CS$4$0000)
  IL_0001:  ldstr      "maChaine!"
  IL_0006:  newobj     instance void
MonNamespace.Program/MaClasse::.ctor(string)
  IL_000b:  stloc.0
  .try
  {
    IL_000d:  ldloc.0
    IL_000e:  callvirt   instance string
MonNamespace.Program/MaClasse::get_MaChaine()
    IL_0013:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_001a:  leave.s    IL_002c
  }  // end .try
  finally
  {
    IL_001c:  ldloc.0
    IL_001d:  ldnull
    IL_001e:  ceq
    IL_0020:  stloc.1
    IL_0021:  ldloc.1
    IL_0022:  brtrue.s   IL_002b
    IL_0024:  ldloc.0
    IL_0025:  callvirt   instance void
[mscorlib]System.IDisposable::Dispose()
    IL_002b:  endfinally
  }  // end handler
  IL_002d:  ret
} // end of method Program::Main

Ceci étant dit, il y a un coût aux blocs using, mais c'est super pratique quand même. On s'en sert surtout avec les objets GDI+ (qui ont des handles bruts) mais aussi dans une tonne de cas dont je te donne deux exemples :

• quand on veut forcer une portée pour l'utilisation du curseur Wait, on a une classe WaitCursor qui, dans le constructeur met le curseur courant à Wait et le remet à Default dans la méthode Dispose();
• pour faire du calcul de performance [using (new PerformanceTimer("Ici, c'est Pepsi")) { ... }]. Toutefois, on s'est rendu compte qu'on perdait un temps fou à cause de la clause try/ finally, alors on ne l'utilise plus.

Si tu veux en savoir plus, je ne saurais trop te référer à l'unique référence valable pour tout ce qui touche à .NET: le livre Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, de Brad Abrams et Krzysztof Cwalina, deux des architectes principaux derrière le .NET Framework, avec des commentaires de monuments comme Anders Hejlsberg (le gars derrière Pascal – remarque de Patrice : ça, en fait, c'est Niklaus Wirth, mais Hejlsberg a contribué à certaines versions de Turbo Pascal – Delphi et C#). Ils expliquent quoi faire et quoi ne pas faire quand on fait des bibliothèques publiques avec .NET et expliquent leur choix (et avouent leurs torts!). Fascinant livre.