Introduction aux traits

Les traits constituent une technique à la fois simple, extrêmement utile et méconnue de la plupart des programmeurs. Les traits permettent d'obtenir, à la compilation, de l'information quant à certains types de données mais pris sur une base générique. Il s'agit à la fois d'une stratégie en soi très abstraite et aux applications très concrètes.

Mise en situation – des traits, pourquoi au juste?

La technique des traits est à la fois belle, extrêmement efficace et très abstraite, reposant sur une double abstraction. C'est pourquoi je vais essayer, à la demande légitime d'ami(e)s et lectrices/ lecteurs estimé(e)s (allo Lamine Sy!), d'expliquer pourquoi on y aurait recours et, au passage, de donner une brève idée générale de ce que cela peut bien être.

Imaginons qu'un programme ayant recours à de la programmation générique contienne un sous-programme applicable à tout type numérique capable de représenter une valeur négative. Imaginons aussi que ce programme veuille lever une exception dans le cas où on chercherait à l'utiliser avec un type numérique pour lequel seuls les nombres positifs sont admis (un type tel que unsigned int par exemple. Ce n'est pas un grand exemple de design logiciel, soit, mais c'est simple et ça fera l'affaire.

#include <limits>
#include <iostream>
using namespace std;
template <class T>
   T abs(const T &val) {
      static_assert(numeric_limits<T>::is_signed, "ne s'applique qu'aux types signés");
      return val < 0? -val : val;
   }

int main() {
   int i = -4;
   cout << abs(i) << endl; // Ok.
   unsigned int ui = 5;
   // ne compilerait pas
   // cout << abs(ui) << endl;
}

#include <type_traits>
class type_signe {};
class type_non_signe {};
template <class T>
   T abs(const T &val, type_signe) {
      return val < 0? -val : val;
   }
template <class T>
   T abs(const T &val, type_non_signe) {
      return val;
   }
template <class T>
   T abs(const T &val) {
      using namespace std;
      return abs(
         val, conditional_t<numeric_limits<T>::is_signed, type_signe, type_non_signe>{}
      );
   }

Si notre souhait est de rédiger un tel programme, alors il nous faut être en mesure de découvrir de l'information quant au type auquel le sous-programme générique sera appliqué. Dans notre cas, pour le type T auquel la fonction abs() est appliquée, il faut savoir s'il est possible de représenter une valeur négative – donc de savoir si, à l'instar des types int et double par exemple, le type T est un type signé.

Cette métadonnée (une information disponible au programme sur les types qui y sont utilisés) est ce qu'on nomme un trait. Avoir accès à des traits dès la compilation permet de rédiger des programmes qui sont à la fois génériques et très efficaces, du fait que le compilateur a lui-même accès à l'information sur les traits et peut procéder à toute la gamme des optimisations possibles.

Des traits permettent donc la jonction entre métadonnées, généricité et efficacité, ce qui entraîne un niveau de flexibilité dans bien des cas comparable à celui des systèmes supportant pleinement la réflexion mais offrant en même temps la performance d'un langage compilé.

Exemple concret de traits – décrire un lieu

Prenons par exemple l'idée d'un point sur un plan 2D. Le type par lequel on exprimera la position en abcisses et en ordonnées du point dépendra du type utilisé pour représenter les coordonnées du plan lui-même, du moins si l'objectif est de faire une classe Point capable de représenter un point dans plusieurs catégories d'espaces.

Le problème de définir une classe Point respectant les règles de l'espace dans lequel cette classe sera utilisée est un problème de détermination de règles applicables à des types, ce qui est une problématique distincte de celle de définir une classe représentant un point et de celle de définir une classe représentant un espace.

Débutons notre exemple avec quelques outils primitifs. Si notre objectif est de déterminer un système de coordonnées et un système de différences entre coordonnées en fonction de règles abstraites, nous mettrons de l'avant deux prédicats capables d'évaluer si une valeur d'un type donné se situe entre deux bornes du même type, ce qui nous donnera la capacité de vérifier si une coordonnée d'un point se situe entre les bornes de validité déterminées par l'espace où il est utilisé:

template <class T>
   constexpr bool est_entre_inclusif(const T &val, const T &borne_inf, const T &borne_sup) {
      return borne_inf <= val && val <= borne_sup;
   }
template <class T>
   constexpr bool est_entre_exclusif(const T &val, const T &borne_inf, const T &borne_sup) {
      return borne_inf < val && val < borne_sup;
   }

La seule contrainte imposée aux types sujets à être utilisés à titre de paramètres pour ces prédicats est qu'ils doivent être comparables à l'aide des opérateurs < et <= et que ces opérateurs doivent être des prédicats laissant inchangé le contenu de leurs paramètres.

Définissons maintenant les traits d'un lieu. Si nous souhaitons être génériques, nous voudrons y aller d'un template comme celui-ci :

template <class D, class P>
   struct TraitsLieu {
      using distance_type = D;
      using position_type = P;
      static constexpr position_type origineX() {
         return {};
      }
      static constexpr position_type origineY() {
         return {};
      }
   };

Les traits d'un lieu seront d'avoir un type pour exprimer une distance et un type pour exprimer une position, de même que d'être capable de décrire son origine. Par défaut, l'origine sera à la position {0,0} d'un système de coordonnées, ce qui présume que le type utilisé à titre de position dans un lieu (donc à titre de TraitsLieu<D,P>::position_type) aura un constructeur par défaut.

Comment décririons-nous l'espace que représente l'écran console classique (25 lignes et 80 colonnes) à partir de ces traits? Une possibilité serait :

class EcranConsole : public TraitsLieu<short,short> {
   enum : position_type { X_MIN = 0, X_MAX = 79, Y_MIN = 0, Y_MAX = 24 };
public:
   static constexpr bool est_lieu_legal(position_type X, position_type Y) {
      return est_entre_inclusif(X, origineX(), X_MAX) &&
             est_entre_inclusif(Y, origineY(), Y_MAX);
   }
   static constexpr position_type origineX() {
      return X_MIN;
   }
   static constexpr position_type origineY() {
      return Y_MIN;
   }
};

On aurait pu faire encore mieux dans le cas de TraitsLieu comme dans le cas d'EcranConsole, mais je vous laisser ces raffinements à titre d'exercice.

#include <limits>
template <class T>
   void init_min(T &val) {
      val = std::numeric_limits<T>::min();
   }

Voyez déjà quelques traits des traits (pardonnez-moi le calembour) :

• La classe représentant les traits (d'un lieu ou de quoi que ce soit d'autre) est une abstraction sujette à être raffinée
• Une application d'une classe de traits est une autre classe dont le rôle est de spécifier ces traits pour un type ou un groupe de types
• On pourrait dire des traits qu'ils constituent une sorte de stratégie pour induire une forme de polymorphisme, sur la base des types, à la compilation. Du métapolymorphisme, en quelque sorte

Exemple d'utilisation de traits – un point générique

Comment exprimer une classe Point capable d'exploiter, dans sa définition, les traits de son lieu? En deux temps :

• Tout d'abord en décrivant une classe plus générique (que je nommerai ici PointBase) décrivant un point en fonction d'un lieu et de ses traits, puis
• En définissant un alias (que je nommerai Point, mais que j'aurais pu nommer PointConsole) combinant un point générique et un lieu

Le nom utilisable se voudra naturel (Point) alors que le nom générique se voudra descriptif de son rôle fondamental (au sens de rôle de fondation).

Le code que je vous propose suit :

template <class Lieu2d = EcranConsole>
   class PointBase {
   public:
      using Lieu = Lieu2D;
      using distance_type = typename Lieu2D::distance_type;
      using position_type = typename Lieu2D::position_type;
      struct PointDiff {
         distance_type dx;
         distance_type dy;
         constexpr PointDiff(distance_type dx, distance_type dy) : dx{ dx }, dy{ dy } {
         }
      };
   private:
      position_type x_, y_;
   public:
      class PointIllegal {};
      constexpr PointBase() : x_{ Lieu::origineX() }, y_{ Lieu::origineY() } {
      }
      PointBase(position_type x, position_type y) : x_{ x }, y_{ y } {
         if (!Lieu2D::est_lieu_legal(x(), y())) throw PointIllegal{};
      }
      constexpr position_type x() const {
         return x_;
      }
      constexpr position_type y() const {
         return y_;
      }
      PointBase & operator+=(const PointDiff &p) {
         return *this = PointBase { x() + p.dx, y() + p.dy) }
      }
      constexpr bool operator==(const PointBase &p) const {
         return x() == p.x() && y() == p.y();
      }
      constexpr bool operator!=(const PointBase &p) const {
         return !(*this == p);
      }
   };
using Point = PointBase<>;

Notez que l'exemple utilise l'écran console comme lieu par défaut. Une autre choix aurait été de laisser l'en-tête de PointBase indiquer simplement template <class Lieu2D> class PointBase puis de définir l'alias Point sous la forme typedef PointBase<EcranConsole> Point;.

La plupart des opérations sont évidentes et indépendantes du type utilisé pour représenter une coordonnée :

• Deux instances de Point sont jugées égales si et seulement si elles ont les mêmes coordonnées en x et en y
• Affecter un Point à un autre Point implique de copier les coordonnées de la source à la destination
• Un Point par défaut est situé à l'origine du lieu qui lui sert de référent
• Un Point auquel on cherche à imposer des coordonnées illégales dans le lieu qui lui sert de référent lève une exception de type PointIllegal
• Toute classe représentant un point contient aussi une classe interne et publique nommée PointDiff, capable de représenter une différence entre deux points, ce qui permet d'exprimer des déplacements dans un lieu à l'aide de valeurs qui pourraient ne pas être légales pour le Point en soi. Les règles servant à prendre en charge une distance entre deux points sont moins astreignantes que celles assurant la validité d'un point

Un trait, donc, est un type générique permettant de décrire les règles applicables à une catégorie de types (les limites des types numériques; les lieux en 2D; les itérateurs; etc.) de manière telle qu'on puisse en tirer profit à la compilation.

Application concrète des traits – une chaîne de caractères insensible à la casse

La question « Comment rédiger une chaîne de caractères insensible à la casse » est une question récurrente en informatique et est beaucoup plus complexe qu'il n'y paraît à première vue, dans la mesure où sont prises en considération les questions d'internationalisation, qui influencent entre autres le traitement de caractères accentués.

Répondre efficacement à cette question est plus facile en pensant le problème de la comparaison de caractères de manière distincte du problème de la gestion des chaînes de caractères. En fait, si nous savons comparer efficacement des caractères entre eux de manière insensible à la casse, alors nous devrions (dans une approche OO) pouvoir compter sur les algorithmes généraux de manipulation de chaînes de caractères et profiter du meilleur des mondes

Comprendre (brièvement) les chaînes de caractères standards de C++

La bibliothèque standard de C++ propose une chaîne de caractères générique, le modèle (template) std::basic_string. Ce modèle décrit une chaîne de caractères en fonction de certains critères parmi lesquels on trouve le type d'un caractère et les traits (surprise!) qui lui sont applicables.

Un certain nombre de traits sont requis, incluant la capacité :

• De vérifier si deux caractères sont égaux ou non (méthode de classe eq(), un prédicat qu'on veut très rapide à l'exécution)
• De déterminer une relation d'ordre entre deux caractères (méthode de classe lt(), un autre prédicat qu'on veut très rapide à l'exécution), et
• De comparer deux séquences de caractères (retournant -1, 0 ou 1 selon le résultat de la comparaison lexicographique réalisée), ceci étant la responsabilité de la méthode de classe compare()

Par défaut, pour un type T, les traits utilisés seront ceux décrits par la classe std::char_traits<T>, ce qui est raisonnable. Cela dit, il est possible de suppléer une autre classe de traits si le coeur nous en dit.

La classe std::string est en fait un alias pour le type générique std::basic_string appliqué au type char avec les traits std::char_traits<T>.

Une classe standard existe aussi pour les caractères 16 bits (en fait, les caractères étendus, puisque la taille exacte n'est pas fixée par le standard), donc le type wchar_t : il s'agit de la classe std::wstring qui est un alias pour le type générique std::basic_string appliqué au type wchar_t avec les traits std:char_traits<wchar_t>.

Un truc bien connu – le type ustring

Dans mes cours de SCS, mentionnés plus haut, je propose régulièrement à mes étudiant(e)s de se construire leur propre chaîne de caractères basée sur des caractères non signés (des unsigned char) du fait que l'interopérabilité est, dans ces cours, l'une des principales problématiques à adresser et du fait que le standard ISO de C++ ne dicte pas le signe du type char. Les gens responsables d'implémenter des compilateurs pour une plateforme ou l'autre sont laissés libres de choisir la straégie la plus efficace pour leurs besoins.

En fait, en C++, peu importe le caractère signé ou non du type char, les types char, signed char et unsigned char sont tous trois considérés distincts.

La conversion d'un unsigned char en char est implicite (quoiqu'elle demande une certaine prudence) sur toutes les plateformes, mais le recours à un reinterpret_cast devient nécessaire si le besoin se fait sentir de convertir, par exemple, un unsigned char * en char * même si les deux sont en fait des bytes non signés sur une plateforme donnée. Cette contrainte est sage quand on considère les dégâts potentiels que permettrait la conversion implicite entre pointeurs non apparentés.

Le fait qu'il soit nécessaire, pour réaliser une forme d'interopérabilité entre modules écrits dans des langages différents, de s'entendre sur la nature et la structure des types de données utilisés de part et d'autre, le type char est disqualifié d'office pour cette tâche. En retour, ce type demeure celui à privilégier pour les opérations internes (en comparaison avec les types signed char et unsigned char ) du fait qu'il est nécessairement celui des trois sur lequel les opérations sont les plus efficaces.

Pour fins d'interopérabilité, donc, mes étudiant(e)s doivent souvent utiliser des types dont le caractère signé ou non est connu a priori, mais il reste beaucoup plus simple (et beaucoup, beaucoup plus sécuritaire) d'utiliser des objets efficaces et solides que d'avoir recours à des tableaux bruts et à des manipulations de bas niveau. Je leur suggère donc de se définir leur propre chaîne de caractères, que nous nommons habituellement ustring (par symétrie avec std::wstring) et qui permet de manipuler des séquences de caractères non signés.

La stratégie est simple: crér une instanciation du type std::basic_string appliquée au type unsigned char puis définir les opérations de base requises pour parvenir à se servir de ce type avec les flux standard (car les entrées/ sorties sont des opérations extrêmement communes sur des chaînes de caractères).

#ifndef USTRING_H
#define USTRING_H
#include <string>
#include <iosfwd>

using ustring = std::basic_string<unsigned char> ustring;

//
// Par défaut, ne sont pas définis sur notre nouveau type
//
std::ostream& operator<<(std::ostream&, const ustring&);
std::istream& operator>>(std::istream&, ustring&);
std::istream& getline(std::istream&, ustring&);

#endif

#include "ustring.h"
#include <string>
#include <iostream>
#include <algorithm>
// ... using ...
ostream& operator<<(ostream &os, const ustring &us) {
   for(auto c : us) os << c;
   return os;
}
istream& operator>>(istream &is, ustring &us) {
   if (!is) return is;
   if (string s; is >> s)
      us = { begin(s), end(s) };
   return is;
}
istream& getline(istream &is, ustring &us) {
   if (!is) return is;
   if (string s; getline(is, s))
      us = { begin(s), end(s) };
   return is;
}

Remarquez la grande simplicité du code proposé ici :

• Présumant que les opérations d'entrée/ sortie sur une instance de std::string soient efficaces et robustes (ce qui est effectivement vrai), et
• Présumant que la copie d'un conteneur à partir d'une paire d'itérateurs sur des données dont le type est compatible avec le type de destination (copier un char dans un unsigned char est tout à fait légal, et il en va de même pour l'opération inverse) soit aussi une opération efficace
• Nous venons d'écrire, en deux temps trois mouvements, des opérations d'entrée/ sortie complexes sur un type dont nous n'avons pas vraiment eu à étudier la structure interne, le tout en nous conformant au standard

Voilà le fruit d'une encapsulation stricte et d'un design de bonne qualité.

ustring us = "allo"; // ne compile pas

Attaquer le problème de la chaîne de caractères insensible à la casse

Dans le même ordre d'idées, nous créerons une chaîne de caractères insensible à la casse sans réécrire le type std::basic_string au grand complet.

La différence entre la stratégie déployée pour le type ustring plus haut et le type ncstring proposé ici est que plutôt que de spécialiser le modèle std::basic_string sur un type de données distinct, nous allons proposer une spécialisation sur le type char avec les traits propres à ce type mais avec, en plus, une spécialisation de comportement pour ce qui est de la comparaison de caractères pris un à un ou en tant que séquence brute.

Notre programme de test ira comme suit :

#include "ncstring.h"
#include <iostream>
int main() {
   using namespace std;
   ncstring nc = "allo";
   ncstring ncOk = "Allo";
   ncstring ncBof = "hello";
   if (nc == ncOk && nc != ncBof)
      cout << "Tout va bien" << endl;
   else
      cout << "Oups!" << endl;
   cout << nc << endl;
}

Nos attentes sont que le programme affiche "Tout va bien" sur une ligne puis "allo" sur la ligne suivante, du fait que les variables nc et ncOk sont égales (en terme de contenu) à la casse près alors que les variables nc et ncBof sont différentes.

Nous souhaitons aussi que nc puisse être affichée normalement, comme toute autre chaîne de caractères.

Le code requis pour définir le type ncstring (le préfixe nc signifiant ici No Case, donc insensible à la casse) va comme suit.

#ifndef NCSTRING_H
#define NCSTRING_H

#include <string>
#include <locale>
#include <iosfwd>
class ncstring_traits : public std::char_traits<char> {
   //
   // on a tous les traits de base, et on raffine
   // ceux qui nous préoccupent
   //
public:
   static int compare(const char_type *s0, const char_type *s1, size_t n) {
      for (size_t i = 0; i < n; ++i)
         if (!eq(*(s0 + i), *(s1 + i)))
            return lt(*(s0 + i), *(s1 + i))? -1 : 1;
      return 0;
   }
   static bool eq(const char_type &c0, const char_type &c1) {
      using namespace std;
      const auto &loc = locale{""};
      return toupper(c0, loc) == toupper(c1, loc);
   }
   static bool lt(const char_type &c0, const char_type &c1) {
      using namespace std;
      const auto &loc = locale{""};
      return toupper(c0, loc) < toupper(c1, loc);
   }
};
using ncstring = std::basic_string <char, ncstring_traits>;
//
// Par défaut, ne sont pas définis sur notre nouveau type
//
std::ostream& operator<<(std::ostream&, const ncstring&);
std::istream& operator>>(std::istream&, ncstring&);
std::istream& getline(std::istream&, ncstring&);
#endif

#include "ncstring.h"
#include <iostream>
#include <string>
#include <algorithm>
using namespace std;
ostream& operator<<(ostream &os, const ncstring &ns) {
   return os << string{begin(ns), end(ns)};
}
istream& operator>>(istream &is, ncstring &ns) {
   if (!is) return is;
   if (string s; is >> s)
      ns = ncstring{ begin(s), end(s) };
   return is;
}
istream& getline(istream &is, ncstring &ns) {
   if (!is) return is;
   if (string s; getline(is, s))
      ns = ncstring{ begin(s), end(s) };
   return is;
}

Remarquez que les méthodes de la classe ncstring_traits utilisent des char_type plutôt que des char directement. Le type char_type est un type interne au type std::char_traits et permet de travailler à un plus haut niveau d'abstraction et de généricité, nous détachant du type exact utilisé pour représenter un caractère. Nous en profiterons un peu plus bas.

Les entrées/ sorties sont implémentées selon précisément la même stratégie que dans le cas du type ustring , plus haut. Les traits, quant à eux, sont écrits avec un peu de désinvolture en ne prennent pas les accents en compte (mais rien de vous empêche de raffiner les méthodes eq() et lt() de la classe ncstring_traits).

Élever le niveau d'abstraction pour couvrir plusieurs types primitifs

#include "ncstring.h"
#include <iostream>
int main() {
   // ... using ...
   ncwstring nc = L"allo";
   ncwstring ncOk = L"Allo";
   ncwstring ncBof = L"hello";
   if (nc == ncOk && nc != ncBof)
      cout << "Tout va bien" << endl;
   else
      cout << "Oups!" << endl;
   wcout << nc << endl;
}

Il n'y a pas de bonne raison de s'arrêter ici, sinon la paresse. En effet, avec un tout petit peu plus d'effort, nous serons capables de couvrir à la fois les petits caractères(qui sont typiquement du type char) comme les plus gros (des wchar_t).

Examinons le programme proposé à droite. Au fait que le type primitif sous-jacent aux diverses opérations soit ici wchar_t plutôt que char, nous faisons face à un clone du programme de test proposé lors de notre première version de la classe ncstring, plus haut.

Tout(e) informaticien(ne) digne de ce nom s'attendra à ce que le bon fonctionnement de l'un d'entre eux implique le bon fonctionnement de l'autre, et c'est une attente tout à fait raisonnable.

Nous devons donc, à tout le moins par professionnalisme, terminer le travail et proposer une classe de traits capable de couvrir à la fois les comparaisons de char et de wchar_t à l'aide de séquences dont le nom reste évocateur des types standard (ici, les types que nous proposons sont ncstring pour la spécialisation sur des petits caractères et ncwstring pour celle s'appliquant à de gros caractères.

Les modifications requises pour en arriver élégamment à une solution capable de couvrir les deux cas impliqueront une élévation du niveau de généricité: nous allons faire de notre classe de traits, ncstring_traits, un template applicable à tout type pour lequel il existe un std::char_traits conforme au standard (donc, à toutes fins pratiques, applicable à tout type capable de se comporter comme un caractère).

Le code suit.

#ifndef NCSTRING_H
#define NCSTRING_H
#include <string>
#include <locale>
#include <iosfwd>
template <class T>
   struct ncstring_traits : std::char_traits<T> {
      static int compare(const char_type *s0, const char_type *s1, size_t n) {
         for (size_t i = 0; i < n; ++i)
            if (!eq (*(s0 + i), *(s1 + i)))
               return lt(*(s0 + i), *(s1 + i))? -1 : 1;
         return 0;
      }
      static bool eq(const char_type &c0, const char_type &c1) {
         using namespace std;
         const auto &loc = locale{""};
         return toupper(c0, loc) == toupper(c1, loc);
      }
      static bool lt(const char_type &c0, const char_type &c1) {
         using namespace std;
         const auto &loc = locale{""};
         return toupper(c0, loc) < toupper(c1, loc);
      }
   };
using ncstring = std::basic_string <char, ncstring_traits<char>>;
using ncwstring = std::basic_string <wchar_t, ncstring_traits<wchar_t>>;
template <class T>
   std::basic_ostream<T>& operator<<(std::basic_ostream<T> &os, const std::basic_string <T, ncstring_traits<T> > &ns) {
      return os << std::basic_string<T>{ std::begin(ns), std::end(ns) };
   }
template <class T>
   std::basic_istream<T>& operator>>(std::basic_istream<T> &is, std::basic_string <T, ncstring_traits<T> > &ns) {
      if (!is) return is;
      if (std::basic_string<T> s; is >> s)
         ns = std::basic_string<T>{ std::begin(ns), std::end(ns) };
      return is;
   }
template <class T>
   std::basic_istream<T> & getline (std::basic_istream<T> &is, std::basic_string <T, ncstring_traits<T> > &ns) {
      if (!is) return is;
      if (std::basic_string<T> s; getline(is, s))
         ns = std::basic_string<T>{ std::begin(s), std::end(s) };
      return is;
   }

#endif

Il y a là clairement plus de code d'écrit, mais il n'y a par contre pas un accroissement du niveau de difficulté: le code est le même dans chaque cas!

La classe de traits ncstring_traits élève son niveau de généricité en se définissant en terme du type de caractère sous-jacent. Aucun coût n'est encouru à l'exécution du fait que les types générés le sont tous sur demande et sont tous pleinement visibles du compilateur, donc susceptibles d'être soumis à une optimisation agressive de leurs méthodes.

Le code de la classe de traits ne change pas d'un poil du fait que cette classe était déjà rédigée en terme de types internes (quelle sage pratique!). Le nom interne char_type est nécessairement le bon type, peut importe le type T effectivement utilisé.

Les noms ncstring et ncwstring correspondent, tel qu'on s'y serait attendu, à des chaînes de caractères standard utilisant des traits pour lesquels la comparaison ne tient pas compte de la casse. C'est là le mandat que nous nous étions fixés.

Les opérations d'entrée/ sortie sont plus subtiles. Pour qu'il soit possible de tirer pleinement profit de ce niveau de généricité ajouté, il nous faut proposer chacune d'entre elles sous sa forme plus générale (car qui sait vraiment quels types seront utilisés dans les programmes se servant de nos traits génériques?).

Ainsi, chaque opération d'entrée/ sortie doit se décliner dans une version tenant compte du type de caractère sous-jacent (donc en fonction du type T). Nous ne voulons pas couvrir toutes les combinaisons possibles de type de caractère et de type de trait (les nombre de combinaisons possible est un infini potentiel, et le nombre de cas typiques connus au préalable est trop grand).

Notre stratégie est donc :

• De proposer chaque opération pertinente comme opérant sur le type T de la séquence en cours d'utilisation (ce qui permettra entre autres de les rendre adaptables à la fois aux flux définis sur des char comme le sont std::cout et std::cin et aux flux définis sur des wchar_t comme le sont std::wcout et std::wcin
• De se servir de std:basic_string<T> lorsque le but est d'utiliser les services existants pour une séquence standard de caractères telle que std::string ou std::wstring et de spécifier std:basic_string<T, ncstring_traits<T> > lorsque nous voulons clairement indiquer la version ne tenant pas compte de la casse, et
• D'offrir les alias ncstring et ncwstring pour faciliter la vie des programmeuses et des programmeurs

Le gain de généricité encouru est considérable, et le coût en espace comme en vitesse est nul. Les traits constituent un atout immense dans la mise au point de stratégies de qualité.

Lectures complémentaires

Quelques liens pour en savoir plus.

• Texte d'Andrei Alexandrescu sur une technique de « traits en stéroïdes » : http://erdani.com/publications/traits_on_steroids.html
• Les traits standards, expliqués par Garfee Guan et Yvonne Ma en 2014 : https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/introduction_to_type_traits_in_the_c_standard_library?lang=en
• Les traits, expliqués par Glennan Carnie en 2014 : https://blog.feabhas.com/2014/09/traits-classes/
• À propos du type pointer_traits, texte de Doug Judd en 2015 : http://blog.nuggetwheat.org/index.php/2015/09/01/why-pointer_traits-was-introduced-in-c11/
• Utiliser des traits pour fins d'optimisation, selon Rainer Grimm en 2016 : http://www.modernescpp.com/index.php/type-traits-performance-matters
• Écrire son propre prédicat sur un type, par Andrzej Krzemieński en 2017 : https://akrzemi1.wordpress.com/2017/12/02/your-own-type-predicate/