Code de grande personne – le truc de Barton-Nackman

Il y a, au moment d'écrire ces lignes, une forte mode autour des schémas de conception en informatique. Les schémas de conception, en gros, sont des (bonnes) façons de faire habituellement transférables d'un langage de programmation à l'autre, bien qu'il arrive souvent que l'exigence de base soit que le langage soit orienté objet (OO).

Parmi les schémas de conception, on trouve ce qu'on nomme des idiomes, qui sont de bonnes pratiques qui peuvent ne pas être transférables à d'autres langages (toute technique exploitant l'idée de constante et de destructeur déterministe dans un langage comme C++ est non transférable tel quel à Java ou à C#, par exemple). Voici donc un petit article sur un idiome de programmation générique en C++ qu'on nomme le truc de Barton-Nackman, du nom de ses auteurs.

À la demande d'un ami (allo Lamine Sy!) qui lit occasionnellement les articles sur h-deb et a la gentillesse de me faire un rapport critique et de souligner les coquilles (ce que je vous invite toutes et tous à faire!), j'ai choisi de mieux mettre en contexte ce truc plutôt que d'arriver à froid dans le sujet, intéressant mais quand même un peu corsé.

À quoi sert le truc?

En programmation orientée objet (POO), une classe enfant spécifie la ou les classe(s) dont elle dérive dès sa déclaration. En ce sens, il est légitime de dire qu'en POO, un enfant connaît ses parents mais un parent ne connaît jamais ses enfants.

Cependant, la métaprogrammation que permet la programmation générique (et surtout les templates de C++, qui constituent un véritable langage complet au sens de Turing, contrairement aux generics de Java et aux Generics de C#) nous offre la latitude d'exprimer des programmes à plusieurs niveaux, de manière à informer, dans certaines circonstances, un parent de l'existence de son enfant.

#include <iostream>
using namespace std;
template <class E>
   struct Affichable {
      friend void afficher(const E &e) {
         cout << e;
      }
   };
class Entier : Affichable<Entier> {
   int val;
public:
   Entier(int val) noexcept : val{ val } {
   }
   int valeur() const noexcept {
      return val;
   }
};
ostream& operator<<(ostream &os, const Entier &e) {
   return os << e.valeur();
}
int main() {
   Entier e = 3;
   afficher(e);
}

Il n'y a aucun lien structurel entre Affichable<X> et Affichable<Y> si X et Y sont différents; l'idée de dériver de manière privée d'une classe servant aux fins du truc Barton-Nackman n'est pas liée à la généralisation ou aux similitudes structurelles mais bien à l'extension, sur une base générique, de l'interface de l'enfant.

Par cette technique, il est possible de construire plusieurs nouvelles opérations sur un type si certaines opérations sont déjà en place. De l'extension par réutilisation, en somme.

Exemple concret

Présumons l'existence d'un type T sur lequel est défini un opérateur < duquel découle une relation d'ordre au sens faible (Strict Weak Ordering). On pourrait vouloir compléter le portrait à l'aide des opérateurs <=, > et >= (ce qui serait souhaitable pour fins de convivialité envers les utilisateurs de ce type), mais il est aussi possible de définir ces trois opérateurs à partir de la définition de l'opérateur < sans réelle perte d'efficacité.

L'écriture de ces opérateurs est d'ailleurs relativement simple :

//
// a > b signifie b < a
//
bool operator>(const T &a, const T &b) {
   return b < a;
}

//
// a <= b signifie !(b < a)
//
bool operator<=(const T &a, const T &b) {
   return !(b < a);
}

//
// a >= b signifie !(a < b)
//
bool operator>=(const T &a, const T &b) {
   return !(a < b);
}

Dans chaque cas, le coût supplémentaire est microscopique (dans la mesure où l'opérateur < est correctement écrit), se limitant dans le pire cas à une négation logique. Il existe des cas où il serait préférable de réécrire chacun de ces opérateurs sur une base individuelle, mais cette définition devrait suffire dans la majorité des cas.

Il est envisageable d'écrire ces opérateurs pour chaque classe (à la limite par copier/ coller), mais cela risquerait d'introduire des erreurs bêtes et difficiles à dépister. On voudrait plutôt dire, par exemple, qu'un type donné permet une relation d'équivalence dans la mesure où il expose un opérateur < correctement écrit.

La manière typique de catégoriser une classe est de la faire dériver d'une classe représentant la catégorie visée. Ici, si l'objectif est de définir une classe nombre (par exemple) comme permettant une relation d'équivalence (au sens exprimé plus haut) et si equivalence était une classe de l'espace nommé relation, alors on voudrait définir nombre comme dérivant de relation::ordonnancement.

Le problème est que la relation d'équivalence se définit sur un type et que, comme le dit la maxime OO bien connue, en situation d'héritage, chaque enfant connaît ses parents mais un parent ne connaît pas ses enfants. La question devient donc: comment construire correctement une classe définissant une relation d'équivalence pour ses éventuels enfants?

Le truc de Barton-Nackman

C'est ici qu'entre en scène le truc de Barton-Nackman, un cas particulier de l'idiome tout à fait charmant Curiously Recurring Template Pattern (CRTP).

Cette technique, à la fois simple et subtile, permet de définir dans un parent des opérations génériques (et pas seulement des opérateurs, même si c'est le cas classique par lequel le truc est décrit, ici comme ailleurs) à partir du type de ses enfants, ce qui constitue une forme de polymorphisme à la compilation. Nous examinerons cette technique en l'appliquant à notre problème bien concret.

namespace relation {
   //
   // ordonnancement<T> définit une relation d'équivalence
   // pour T si T::operator< (const T&) const existe.
   //
   template <class T>
      class ordonnancement {
         friend bool operator>(const T &a, const T &b) {
            return b < a;
         }
         friend bool operator<=(const T &a, const T &b) {
            return !(b < a);
         }
         friend bool operator>=(const T &a, const T &b) {
            return !(a < b);
         }
      };
}

class nombre : relation::ordonnancement<nombre> {
   int valeur_ {};
   friend inline bool operator<(const nombre &n0, const nombre &n1) noexcept {
      return n0.valeur() < n1.valeur();
   }
public:
   nombre() = default;
   nombre(int n) noexcept : valeur_{n} {
   }
   //
   // La sainte-trinité (constructeur de copie,
   // affectation, destructeur) est Ok telle
   // quelle; on ne les réécrit pas.
   //
   constexpr int valeur() const noexcept {
      return valeur_;
   }
};
#include <iosfwd>
// implémentation évidente; je vous laisse la faire
std::ostream & operator<<(std::ostream&, const nombre&);

Les éléments essentiels apparaissent en caractères gras. Notez que l'opérateur < est ici défini sous forme de fonction globale (suggestion du sympathique François-Xavier Bourlet), par souci d'homogénéité, mais dans ce cas une méthode d'instance aurait donné les mêmes résultats.

Notez tout d'abord que l'opérateur < est défini sur nombre, remplissant ainsi le contrat de cette classe (sa classe parent, relation::ordonnancement<nombre>, en dépend). L'implémentation de l'opérateur est très simple dans ce cas-ci mais toute implémentation sémantiquement correcte aurait fait l'affaire.

Ensuite, remarquez que nombre dérive de manière privée (et non pas publique) de relation::ordonnancement<nombre>. L'intention ici est de procéder à de l'héritage d'implémentation stricte, pas à une forme ou l'autre de design visant une éventuelle utilisation polymorphique.

Enfin, et c'est la nature de l'idiome CRTP, la classe parent (générique) se voit injecter à l'instanciation (au sens de la génération par le compilateur de la classe à laquelle s'applique le template) le type de son enfant. Cette technique est possible parce que le nom de l'enfant apparaît avant le nom du parent et existe donc au moment où le parent est généré par le compilateur.

Notez que la classe relation::ordonnancement<nombre> est une classe comme une autre; on aurait pu la nommer rel_ord_nb si notre objectif n'avait pas été de construire de manière générique des opérateurs sur le type de l'enfant. Il n'y a donc pas de circularité entre la définition du parent et de l'enfant, puisque le parent ne connaît toujours pas l'enfant (et ne le contient pas). L'enfant contient le parent, comme à l'habitude. Par contre, l'instanciation de la classe parent, qui la fait passer de générique à existante concrètement, entraîne la génération d'un ensemble de fonctions globales applicables à un autre type, qui (surprise!) se trouve à être l'une de ses classes dérivées.

Le petit programme ci-dessous montre comment il est possible de tester la classe nombre telle que définie à l'aide de cette stratégie.

#include <iostream>
using namespace std;
// ...
int main() {
   nombre n0{4}, n1{4};
   if (n0 <  n1)
      cout << n0 << "< " << n1 << endl;
   if (n0 <= n1)
      cout << n0 << "<=" << n1 << endl;
   if (n0 >  n1)
      cout << n0 << "> " << n1 << endl;
   if (n0 >= n1)
      cout << n0 << ">=" << n1 << endl;
}

Vous pouvez bien sûr modifier les valeurs initiales de n0 et de n1 (3 et 4, disons, puis 4 et 3) pour tester tous les cas pertinents.

Lectures complémentaires

Quelques liens pour enrichir le propos :

Article de 2001 sur l'injection de classes parents par voie de programmation générique, par Douglas Gregor, Sibylle Schupp et David Musser : http://www.osl.iu.edu/publications/prints/2001/GSM01a.pdf

En 2015, Arne Mertz décrit Boost.Operators, qui offrent essentiellement la fonctionnalité décrite ici : http://arne-mertz.de/2015/02/operator-overloading-introduction-to-boost-operators-part-1/

Détails sur la saine application de ce truc, par Arthur O'Dwyer en 2020 : https://quuxplusone.github.io/blog/2020/12/09/barton-nackman-in-practice/