Comprendre la Sainte-Trinité

Il est parfois complexe de s'acclimater aux nuances d'un langage de programmation à l'autre, à plus forte partie lorsque les langages se ressemblent superficiellement mais diffèrent dans leurs fondements. Dans cet article, nous examinerons les nuances quant aux opérations qui touchent au coeur de ce que sont les objets dans un langage OO, c'est-à-dire l'accès à un objet, sa construction, sa finalisation et sa duplication.

L'idée derrière cette réflexion est de comprendre ce qu'on nomme en C++ la Sainte-Trinité, terme souvent remplacé par le plus politiquement correct « règle de trois » (qui, depuis C++ 11, est plus une « règle de cinq »). La Sainte-Trinité (ou « règle de trois ») aurait initialement été énoncée par Marshall Cline en 1991.

Comprendre ces opérations et l'interaction qu'elles ont avec nos programmes nous permet de mieux comprendre l'acte de programmer dans l'un ou l'autre de ces langages.

L'idée de base – Sémantique d'accès

Java et C# font partie des  langages OO pour lesquels la seule sémantique d'accès pour les instances d'une classe donnée est la sémantique de référence :

• Les objets sont tous créés dynamiquement
• Les objets sont tous manipulés indirectement (à travers une référence)
• La récupération des ressources associées à un objet donné est prise en charge par un moteur de collecte d'ordures (heureusement; étant donné la prévalence des accès indirects, procéder autrement entraînerait sans cesse des fuites de ressources)

Dans ces deux langages, ce qui tient lieu de référence est une indirection amovible. Ces références sont commes des pointeurs en C ou en C++ au sens où l'une d'elles peut pointer à null, ou encore pointer vers divers objets au cours de son existence. Ces références diffèrent des pointeurs de C et de C++ au sens où :

• Elles ne permettent pas de butiner en périphérie de la zone mémoire à laquelle elles réfèrent
• Les langages qui les encadrent assurent la  collecte des rebuts, à l'aide de moteurs de collecte d'ordures. Pour de tels langages, ce comportement est essentiel, car il serait difficile d'assurer le suivi de tous les objets créés dynamiquement et leur bon nettoyage (la finalisation, par contre, est un problème très difficile à régler pour ces langages). Voir CPP--Exploiter-Symetrie.html pour en savoir plus

C++, en contrepartie, et un langage OO pour lequel la sémantique d'accès privilégiée est la sémantique de valeur :

• Les objets sont typiquement définis sur la pile et ont une finalisation déterministe
• Allouer des objets dynamiquement demande un effort supplémentaire, et ne devrait être fait que si nécessaire car, dans ce cas, le programme acquiert une responsabilité supplémentaire, soit celle de finaliser explicitement l'objet et de libérer les ressources qui y sont associées. Heureusement, les pointeurs intelligents facilitent grandement cette tâche (vous devriez envisager leur utilisation si vous ne le faites pas déjà)

Ce qu'est la Sainte-Trinité

Puisque C++ supporte et encourage une sémantique d'accès direct aux objets, certaines considérations deviennent particulièrement importantes dans ce langage :

class X { /* ... */ };
X f();
int main() {
   X x = f();
   X y = x; // construction par copie
   // ...
   x = y;   // affectation

// ...
} // appelle y.~X() et x.~X()

Puisque l'identité des objets va de pair avec la programmation en C++, le langage supplée trois (maintenant : cinq!) opérations automatiquement pour tout type :

• Le constructeur de copie. Son comportement par défaut est d'appeler le constructeur de copie pour chacun des attributs
• L'affectation. Son comportement par défaut est d'appeler l'affectation pour chacun des attributs, et
• La destruction, dont le comportement par défaut est de finaliser chacun des attributs

Cas d'espèces

La Sainte-Trinité est implicitement correcte pour une classe dont tous les membres ont eux aussi une Sainte-Trinité correcte, et pour laquelle la sémantique d'une copie est clairement définie. C'est le cas pour tous les types primitifs (incluant les pointeurs; ceux-ci sont implicitement copiables, après tout). Elle doit toutefois être repensée dans les cas où un objet prend explicitement la responsabilité sur des ressources (allocation dynamique de mémoire, ouverture d'un flux, prise en charge d'un mécanisme de synchronisation, etc.). Quelques exemples concrets suivent.

struct Point {
   using value_type = float;
   value_type x, y;
   constexpr Point() : x{}, y{} {
   }
   constexpr Point(value_type x, value_type y) : x{x}, y{y} {
   }
};

class Personne {
   std::string nom_;
   NAS no_ass_sociale_;
public:
   Personne(const std::string &nom, const NAS &nas)
      : nom_{ nom }, no_ass_sociale_{ nas }
   {
   }
   // ...
}};

class inconnu {};
class redondant {};
class Registre {
   vector<const Personne*> individus;
public:
   void ajouter(const Personne *p) {
      if (auto it = find(begin(individus), end(individus), p);
          it != end(individus))
         throw redondant{};
      individus.emplace_back(p);
   }
   void retirer(const Personne *p) {
      if (auto it = find(begin(individus), end(individus), p);
          it == end(individus))
         throw inconnu{};
      else
         individus.erase(it);
   }
   // etc.
};

class TiTableau {
public:
   using size_type = std::size_t;
private:
   size_type nelems{};
   int *elems;
public:
   TiTableau(size_type n)
      : elems{ new int[n] }
   {
      fill(elems, elems+size(), 0);
   }
   TiTableau(const TiTableau &autre)
      : nelems{ autre.size() }, elems{ new int[autre.size()] }
   {
      copy(autre.elems, autre.elems+size(), elems);
   }
   void swap(TiTableau &autre) {
      using std::swap;
      swap(elems, autre.elems);
      swap(nelems, autre.nelems);
   }
   TiTableau& operator=(const TiTableau &autre) {
      TiTableau{ autre }.swap(*this);
      return *this;
   }
   ~TiTableau() {
      delete [] elems;
   }
   // ...
};

class TiTableau {
public:
   using size_type = std::size_t;
private:
   size_type nelems{};
   unique_ptr<int[]> elems;
public:
   TiTableau(size_type n)
      : elems{ new int[n] }
   {
      fill(&elems[0], &elems[size()], 0);
   }
   // ...
};

Dans un langage où l'usage est de manipuler des objets directement, offrir un support automatique de la Sainte-Trinité va de pair avec des principes de base de saine programmation. Évidemment, dans un langage où l'accent est mis sur l'allocation dynamique de ressources, le partage d'objets et l'accès indirect, les pratiques sont différentes. En C# et en Java, mieux vaut penser immuabilité (pour réduire les conséquences néfastes du partage implicite des objets) que d'insister sur la copie des objets, puisque cette dernière opération y est moins naturelle, moins idiomatique.

Comparatif d'opérations clés

Le programme C++ suivant :

class X { /* ... */ };
int main() {
   X x;
}

... n'a pas vraiment d'équivalent en Java ou en C#. En effet, ici, x est une instance de X, à laquelle le programme a directement accès. C# offre un comportement se rapprochant de ceci avec ses struct, et Java n'offre rien qui s'en rapproche.

Le code Java ou C# que l'on pourrait imaginer être « équivalent » au code C++ ci-dessus serait probablement :

// ...
class X
{
   static void Main(string [] args)
   {
      X x = new X();
   }
}
// ...

// ...
class X {
   public static void main(String [] args) {
      X x = new X();
   }
}
// ...

Pourtant, le code C++ le plus proche de ces deux programmes serait plutôt :

#include <memory>
class X { /* ... */ };
int main() {
   using std::shared_ptr;
   auto x = shared_ptr<X>(new X);
}

En effet :

• Dans ces trois exemples (Java, C# et C++ avec shared_ptr), une instance de X est créée dynamiquement et manipulée à travers une indirection (une référence de Java, une référence de .NET ou un pointeur intelligent de C++)
• Dans ces trois exemples utiliser l'affectation sur x signifie partager ce à qui il réfère, pas copier ce à quoi il réfère
• Dans ces trois exemples, à la fin de la portée de x, son pointé est susceptible d'être collecté et détruit. Dans les trois cas, la collecte n'aura vraiment lieu que si x était le dernier responsable de son pointé dans le code client. Cependant, avec C++, le pointé sera détruit immédiatement lors de la déconnexion de son dernier client (du dernier shared_ptr pointant dans sa direction), alors qu'avec C# ou Java, le pointé sera collecté éventuellement

Que chaque création d'objet implique une allocation dynamique de ressources entraîne un coût, évidemment. Il faut chaque fois trouver un endroit pour placer l'objet en cours de création, l'initialiser, puis mettre en place les mécanismes minimaux requis pour assurer le suivi de l'objet en question et, éventuellement, en assurer la collecte.

Chaque copie d'une référence sur l'objet entraîne elle aussi des coûts, du fait qu'il faut alors s'assurer ce que vers quoi la référence pointait précédemment soit informé qu'elle ne pointe plus dans sa direction, tout en informant le nouveau pointé de cette réalité. Au minimum, on parle ici d'une incrémentation et d'une décrémentation de compteurs, les deux de manière synchronisée, ou à tout le moins atomique.

On serait portés à croire que le fait qu'un objet ne soit collecté qu'éventuellement serait quelque chose de péjoratif, mais il n'en est rien, du moins du point de vue des moteurs de ces langages. En effet, ces langages appliquent des stratégies appropriées aux choix qui sont les leurs :

• Les objets dont la vie est de courte durée (ceux créés localement à une méthode) sont pris d'une zone mémoire choisie avec soin et sont alloués rapidement. De même, ils sont typiquement collectés très rapidement suite à la fin de l'exécution de la méthode où ils ont été créés
• De même, un moteur de collecte d'ordures a le loisir de ne jamais collecter d'objets si la mémoire ne vient jamais à manquer. En ce sens, ils peuvent être beaucoup plus efficaces qu'un programme écrit en C++ qui utiliserait beaucoup l'allocation dynamique de mémoire (ce qui n'est pas le cas des programmes C++ typiques, cependant)
• Les moteurs de collecte d'ordures tendent à collecter plusieurs objets d'un coup, ce qui tend à réduire le coût moyen des libérations de ressources (évidemment, les moments effectifs des collectes, eux, peuvent faire mal)
• Les moteurs de collecte d'ordures procéderont typiquement à une phase de compaction de la mémoire lors des collectes, ce qui leur permet de réduire la fragmentation (de l'éliminer, essentiellement). C'est un grand avantage des langages associés à des moteurs de collecte d'ordures, d'ailleurs : en ne donnant pas un accès direct à la mémoire, et en connaissant les détails de tous les objets sous leur gouverne, ils sont en mesure de relocaliser les objets à loisir

Risques du partage

Puisque tous les objets en C# et en Java sont alloués dynamiquement, et puisque la copie dans ces langages est d'abord et avant tout une copie de référence, donc une sémantique de partage du référé, il est très important de développer avec ces langages l'habitude de concevoir des objets immuables.

Par immuable, on entend une classe dont les instances ne peuvent être modifiées une fois construite (pas de mutateurs ou de services semblables). Sans surprise, la plupart des classes importantes de langages comme C# et Java sont immuables (String en Java et string en C# en sont de bons exemples). Pour comprendre les enjeux, voir ce texte.

Partager un objet qui n'est pas immuable est dangereux en situation de multiprogrammation, et prête à risque même en situation de monprogrammation, brisant le principe de moindre surprise. Il est difficile de savoir quand il est le plus opportun de dupliquer un objet mutable (par clonage ou par copie) pour éviter les bris d'encapsulation; les objets faisant partie d'une interface dans ces langages devraient conséquemment tous être immuables.

Quelques comparatifs

À titre de référence, voici quelques comparatifs d'opérations clés dans les principaux langages de programmation au moment d'écrire ceci.

X x;
// ou plus explicitement
X x = {};
// ou encore
X x{};
// ou encore (à votre convenance)
auto x = X{};

X x = new X();
// ou encore
var x = new X();

X x = new X();

X *p = new X;
// ou (mieux)
unique_ptr<X> p { new X };
// ou (mieux)
auto p = make_unique<X>();
// ou, seulement si c'est pertinent
auto p = make_shared<X>();

X x = new X();

X x = new X();

x0 == x1

x0 == x1 // parfois
x0.Equals(x1) // plus général

x0.equals(x1)

p0 == p1

p0 == p1 // prudence

p0 == p1

x0 = x1;

s/o

s/o

x0 = x1

x0 = x1.Clone()

x0 = x1.clone()

Pour bien programmer dans l'un ou l'autre de ces langages, il faut comprendre ces nuances.

Impact du mouvement

Depuis C++ 11, le langage C++ supporte la sémantique de mouvement. Cet article donne plus de détails sur le sujet, mais pour le présent article, ce qui nous intéresse est l'interaction de cette nouvelle sémantique avec la traditionnelle sémantique de copie.

En bref : il est possible depuis C++ 11 d'ajouter aux méthodes clés d'un objet un constructeur de mouvement et une affectation par mouvement. La syntaxe est :

class TiTableau {
public:
   using size_type = std::size_t;
private:
   size_type nelems;
   int *elems;
public:
   TiTableau(size_type n)
      : nelems{}, elems{new int[n]}
   {
      fill(elems, elems+size(), 0);
   }
   TiTableau(const TiTableau &autre)
      : nelems{autre.size()}, elems{new int[autre.size()]}
   {
      fill(autre.elems, autre.elems+size(), elems);
   }
   void swap(TiTableau &autre) {
      using std::swap;
      swap(elems, autre.elems);
      swap(nelems, autre.nelems);
   }
   TiTableau& operator=(const TiTableau &autre) {
      TiTableau{ autre }.swap(*this);
      return *this;
   }
   ~TiTableau() {
      delete [] elems;
   }
   // ...
};

class TiTableau {
public:
   using size_type = std::size_t;
private:
   size_type nelems{};
   int *elems;
public:
   TiTableau(size_type n)
      : elems_{new int[n]}
   {
      fill(elems, elems+size(), 0);
   }
   TiTableau(const TiTableau &autre)
      : nelems{ autre.size() }, elems{ new int[autre.size()] }
   {
      copy(autre.elems, autre.elems+size(), elems);
   }
   void swap(TiTableau &autre) {
      using std::swap;
      swap(elems, autre.elems);
      swap(nelems, autre.nelems);
   }
   TiTableau& operator=(const TiTableau &autre) {
      TiTableau{ autre }.swap(*this);
      return *this;
   }
   ~TiTableau() {
      delete [] elems;
   }
   //
   // Construction par mouvement: les états du paramètre sont transférés
   // dans l'objet en cours de construction. L'objet original est laissé
   // dans un état qui permettra de le détruire sans risque
   //
   TiTableau(TiTableau && autre)
      : elems{std::move(autre.elems)}, nelems{std::move(autre.nelems)}
   {
      autre.nelems = 0;
      autre.elems = nullptr;
   }
   //
   // Affectation par mouvement: les états du paramètre sont transférés
   // dans l'objet en cours de construction. L'objet original est laissé
   // dans un état qui permettra de le détruire sans risque
   //
   TiTableau& operator=(TiTableau && autre) {
      if (&autre != this) {
         delete [] elems;
         elems = autre.elems;
         nelems = autre.nelems;
         autre.elems = {};
         autre.nelems = {};
      }
      return *this;
   }
   // ...
};

class TiTableau {
public:
   using size_type = std::size_t;
private:
   size_type nelems{};
   unique_ptr<int []> elems;
public:
   TiTableau(size_type n)
      : elems{ new int[n] }
   {
      fill(&elems[0], &elems[size()], 0);
   }
   TiTableau(const TiTableau &autre)
      : nelems{ autre.size() }, elems{ new int[autre.size()] }
   {
      copy(&(autre.elems)[0], &(autre.elems)[size()], &elems[0]);
   }
   void swap(TiTableau &autre) {
      using std::swap;
      swap(elems, autre.elems);
      swap(nelems, autre.nelems);
   }
   TiTableau& operator=(const TiTableau &autre) {
      TiTableau{ autre }.swap(*this);
      return *this;
   }
   ~TiTableau() = default;
   //
   // Construction par mouvement: les états du paramètre sont transférés
   // dans l'objet en cours de construction. L'objet original est laissé
   // dans un état qui permettra de le détruire sans risque
   //
   TiTableau(TiTableau &&) = default;
   //
   // Affectation par mouvement: les états du paramètre sont transférés
   // dans l'objet en cours de construction. L'objet original est laissé
   // dans un état qui permettra de le détruire sans risque
   //
   TiTableau& operator=(TiTableau &&) = default;
   // ...
};

Les règles décrivant l'impact de la sémantique de mouvement sur la Sainte-Trinité sont les suivantes :

• Par défaut, le compilateur générera les cinq méthodes en leur donnant le sens suivant :
  • le constructeur de copie appelle le constructeur de copie des parents et des attributs, un à un
  • l'affectation appelle l'affectation des parents et des attributs, un à un
  • le destructeur appelle le destructeur des attributs et ceux des parents, un à un
  • le constructeur de mouvement appelle le constructeur de mouvement des parents et des attributs, un à un
  • l'affectation par mouvement appelle l'affectation par mouvement des parents et des attributs, un à un
• Si un objet déclare qu'il prend en charge au moins l'une des opérations de la Sainte-Trinité plutôt que de laisser opérer les versions générées par le compilateur, alors cela laisse entendre que l'objet doit assurer explicitement le respect de certains invariants. Pour cette raison, dans ce cas, le compilateur ne générera pas les opérations de mouvement de manière automatique, et le mouvement ne sera possible que si la classe implémente les méthodes requises explicitement
• De même, si un objet déclare qu'il prend en charge au moins l'une des opérations clés du mouvement plutôt que de laisser opérer les versions générées par le compilateur, alors cela laisse entendre que l'objet doit assurer explicitement le respect de certains invariants. Pour cette raison, dans ce cas, le compilateur ne générera pas la Sainte-Trinité de manière automatique, et le mouvement ne sera possible que si la classe implémente les méthodes requises explicitement

Résumé des pratiques clés avec C++

Avec C++, les règles suivantes guident la définition des opérations clés déterminant le comportement d'un objet en tant qu'entité. Dans ce qui suit, « tenir compte » signifie ne pas laisser le compilateur procéder par défaut, peu importe comment.

Lectures complémentaires

Quelques liens pour en savoir plus.

• Pour une source plus officielle mais moins raffinée, voir http://en.cppreference.com/w/cpp/language/rule_of_three
• https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-zero
• Texte d'introduction (du Code Project) sur les constructeurs et l'affectation : http://www.codeproject.com/Articles/814403/Cplusplus-Constructors-and-Copy-assignment-Part
• Textes de Glennan Carnie :
  • texte de 2014, qui parle pour sa part de la « règle de trois et demie », la demie étant la méthode swap() telle que préconisée (entre autres) pour implémenter l'idiome d'affectation sécuritaire : https://blog.feabhas.com/2014/12/the-rule-of-the-big-three-and-a-half-resource-management-in-c/
  • texte de 2015, qui parle de la « règle du quatre et demie », incluant cette fois la sémantique de mouvement : https://blog.feabhas.com/2015/01/the-rule-of-the-big-four-and-a-half-move-semantics-and-resource-management/
  • texte de 2015, qui parle de la « règle du zéro » : https://blog.feabhas.com/2015/01/the-rule-of-the-big-four-and-a-half-move-semantics-and-resource-management/
  • texte de 2015 qui parle à nouveau de la « règle du zéro », mais dans une perspective de maximisation de son efficacité : https://blog.feabhas.com/2015/11/becoming-a-rule-of-zero-hero/
• La « règle de cinq », ramenée à son essence : http://www.cppsamples.com/common-tasks/rule-of-five.html
• À propos de la « règle de zéro », texte de Nir Friedman en 2015 : https://turingtester.wordpress.com/2015/06/27/cs-rule-of-zero/
• La « règle de zéro » est moins facilement applicable qu'on pourrait le croire de prime abord. Expérience concrète relatée par Andrzej Krzemieński en 2015 :
  • https://akrzemi1.wordpress.com/2015/09/08/special-member-functions/
  • https://akrzemi1.wordpress.com/2015/09/11/declaring-the-move-constructor/
• En 2015, Arne Mertz parle quant à lui de la « règle du tout ou rien » : http://arne-mertz.de/2015/02/the-rule-of-zero-revisited-the-rule-of-all-or-nothing/
• En 2016, Jonathan Müller parle de la « règle de six », insérant le constructeur par défaut dans le modèle de base des objets en C++ pour éviter ce qu'il considère être un risque de la sémantique de mouvement : https://foonathan.net/2016/08/move-default-ctor/#content
• « Règle de trois », « règle de cinq », « règle de zéro »... Regard porté par Jonathan Boccara en 2019 sur les fonctions autogénérées par un compilateur C++ :
  •  https://www.fluentcpp.com/2019/04/19/compiler-generated-functions-rule-of-three-and-rule-of-five/
  • https://www.fluentcpp.com/2019/04/23/the-rule-of-zero-zero-constructor-zero-calorie/