Opérateurs de conversion C++ ISO

Une conversion explicite de types, ou un transtypage (en anglais : un Cast ou un Typecast, selon la tradition) est un mal nécessaire. Le genre de chose dont nous souhaiterions tous nous passer, qui brise la logique d'un programme et tend à le fragiliser, et qu'on voudrait, dans un monde idéal, en venir à faire disparaître complètement de nos programmes.

Cette conception est un souhait, un idéal, mais ne doit pas être prise en un sens dogmatique. Que ce soit pour des raisons pragmatiques (adaptation à une bibliothèque dont la philosophie diffère de la vôtre), techniques (manipulations de très bas niveau, près du matériel) ou conceptuelles (résoudre par programmation une ambiguité résultant d'un design complexe et d'un requis spécial), il arrive que des conversions explicites de types se glissent dans le portrait.

Notre capacité de faire (éventuellement) disparaître les conversions explicites de types de nos programmes dépend de notre capacité de les y repérer une fois celles-ci introduites. Notre capacité de nous assurer que la conversion appliquée fasse exactement ce que nous souhaitons qu'elle fasse dépend de la précision avec laquelle nous pourrons exprimer nos intentions.

Les conversions explicites de types ISO s'inscrivent dans cette optique :

• Préciser l'intention du programmeur en catégorisant avec rigueur les conversions possibles
• Décourager l'utilisation abusive des conversions en leur donnant une syntaxe un peu lourde, et
• Faciliter leur repérage (et leur éventuelle élimination) en les identifiant à l'aide de mots clés.

Ce que fait un transtypage (une conversion explicite de types)?

Règle générale, la conversion n'est pas vraiment une conversion, au sens où l'objet converti ne change pas. Un conversion explicite de types peut en fait représenter plusieurs opérations distinctes, selon le contexte et les types impliqués :

• Une construction d'un objet temporaire (lorsque le type de destination est un objet et que sa classe expose un constructeur prenant en paramètre le type source), ce qui implique à la fois une opération de construction et une opération de destruction pour la temporaire en question – une telle conversion explicite de types est à la fois relativement sécuritaire et plutôt coûteuse
• Un mensonge, comme dans le cas où le programmeur souhaite faire croire à un compilateur qu'un pointeur ou une référence du type source est en fait un pointeur ou une référence du type de destination. Certains de ces mensonges sont bénins, d'autres sont risqués
• Un retrait d'ambiguité, comme dans une situation d'héritage multiple où on voudrait traiter une instance d'une classe dérivée comme une instance de l'un de ses parents mais où ce parent apparaîtrait plus d'une fois dans la généalogie de l'enfant (un exemple simple de cette situation est proposé ici)
• Un petit mensonge pragmatique, pour faire oublier discrètement le mot const sur une référence ou sur un pointeur lorsqu'un objet est utilisé avec une API pour laquelle les qualifications de constance ont été placées de manière négligente; etc.

Il est important, surtout avec un outil aussi riche et expressif que C++, de pouvoir énoncer clairement laquelle des options doit être choisie. Dans les cas de hiérarchies complexes d'objets, ne pas pouvoir dicter correctement son intention à un compilateur résulterait en des programmes dangereux ou carrément inopérants.

La tradition C (adoptée par Java et C#)

La conversion explicite de types du langage C est une conversion brutale et incontrôlable. C'est une prise de responsabilité de l'informaticien(ne) face à une action contre nature (en fait, foncièrement dénaturante) sur un objet.

La conversion traditionnelle prend la forme du type de destination (donc du type dans lequel une expression sera convertie) placé entre parenthèses et précédant l'expression à convertir. L'exemple ci-dessous montre comment il est possible, selon la tradition, de signaler à un compilateur qu'il doit traiter source comme étant du type de dest.

Dest dest;
Source source;
dest = (Dest) source;// conversion explicite de source au type de dest

C++ admet aussi une notation rejoignant celle des constructeurs pour ces conversions. L'invocation d'un constructeur pour créer une variable temporaire est raisonnable; le problème est que ce n'est peut-être pas là l'intention de la programmeuse ou du programmeur (par exemple, si le programme cherche à traiter un void* en int* dans une fonction du système d'exploitation, l'idée n'est pas tant de créer une variable temporaire que de traiter une adresse typée comme une adresse d'un autre type). La syntaxe ressemble à celle utilisée avec Modula.

Dest dest;
Source source;
dest = Dest(source); // conversion explicite de source au type de dest avec signature de constructeur

Un problème?

Particulièrement en POO, il est complexe – pour le compilateur – de comprendre ce que veut faire la programmeuse ou le programmeur, surtout lorsque l'expression de conversion explicite de types est prise hors contexte.

const X* px = new X;
// ...
pv = (Y*) px; // piache!

Les opérateurs de conversion explicite de type ISO

Le langage C++ a introduit, depuis 1998 environ (arrivée du standard ISO), quatre nouveaux opérateurs de conversion explicite de types.

Ces opérateurs sont listés dans la table ci-dessous. Dans chaque cas, la notation requise pour les utiliser est op<T>(e) où op est l'opérateur de conversion de type, T est le type dans lequel convertir (donc le type de destination) et e est l'expression devant être convertie (la source).

static_cast<T>(e)

dynamic_cast<T>(e)

reinterpret_cast<T>(e)

const_cast<T>(e)

La syntaxe « étrange » : pourquoi?

En principe, une conversion explicite de types n'est jamais souhaitable. L'intention d'une programmeurs ou d'un programmeur devrait être, dans la mesure du possible, en ressortir à des solutions plus naturelles.

L'emploi de la notation traditionnelle de C pour exprimer la conversion de e au type T (et qu'ont adopté Java et C#), qui est (T)e (ou T(e)), complique la recherche dans le code des occurrences de conversions explicites de types – avec cette syntaxe, il est très ardu de chercher une conversion explicite de type à l'aide d'un éditeur de texte sans se frapper sans arrêt à des appels de sous-programmes ou à des opérations d'affectation de priorité sur des opérations usuelles).

L'emploi de noms d'opérateurs plus longs et plus explicites (des noms réservés!) facilite la recherche et l'identification des opérations de conversion explicite de type dans le code. Le dépistage pour fins de débogage ou de nettoyage du code en devient une tâche beaucoup plus raisonnable.

L'emploi de la syntaxe des templates, elle, vise à décourager l'usage de conversions explicites de types dans le code, là où elles pourraient être évitées. C'est une syntaxe volontairement lourde et légèrement pénible à utiliser, qui rend évident le tour de passe-passe qu'est, en fait, la conversion.

L'opérateur static_cast

L'opérateur static_cast permet des conversions qui seraient légales à la compilation (p. ex. : de int à float). Pour ces cas, utiliser un opérateur de conversion explicite de types est redondant.

Cet opérateur permet aussi des conversions du type Base*←(Dérivée*)e qui sont implicitement sécuritaires mais peuvent être nécessaires en situation d'héritage multiple.

class B { /* ... */ };
class D0 : public B { /* ... */ };
class D1 : public B { /* ... */ };
class D : public D0, public D1 { /* ... */ };

void f(D *pD) {
   // B *pB = pD; // illégal car ambigü: il y a deux B dans un D!
   B* pB = static_cast<D1*>(pD); // Ok, ambiguïté levée (aussi Ok si on passe par un D0*)
}

L'opérateur static_cast permet aussi des conversions assez sécuritaires du type Dérivée*←(Base*)e pouvant être validées au moment de la compilation.

class B { /* ... */ };
class D : public B { /* ... */ };
void f (B* pB, D* pD) {
   D* pD2 = static_cast<D*>(pB); // peut être risqué, selon le contexte. Était « (D*)pB »
   B* pB2 = static_cast<B*>(pD); // sécuritaire, implicite
}

Pour certaines conversions malsaines entre types non apparentés, l'opérateur static_cast sera en mesure de générer une erreur de compilation, permettant de dépister plus d'erreurs à la compilation (ce qui est toujours préférable à du débogage une fois le produit livré au client).

Une conversion par l'opérateur static_cast génère du code très efficace en terme de temps d'exécution car elle est réalisée statiquement, donc à la compilation. Cela dit, il est possible de lui jouer des tours.

class B { /* ... */ };
class D : public B { };
void f (B* pb) {
   D* pd1 = static_cast<D*>(pb); // OK si pb est un D*, fort dangereux sinon
}

L'opérateur dynamic_cast

Sert à produire des conversions sécuritaires du type Dérivée*←(Base*)e et pouvant être validées au moment de l'exécution, donc qui sont plus sécuritaires (mais plus lentes, à cause des vérifications qui doivent être faites) que celles réalisées avec static_cast.

L'expression dest = dynamic_cast<Dest>(source); doit se lire comme suit: si source peut être considéré comme un Dest, alors déposer ce Dest dans dest, sinon retourner 0 s'il s'agit d'une tentative de conversion de pointeurs ou lever une exception s'il s'agit plutôt d'une tentative de conversion de références.

class B { /* ... */ };
class D : public B { };
void f(B* pb) {
   D* pd1 = static_cast<D*>(pb);  // (0)
   D* pd2 = dynamic_cast<D*>(pb); // (1)
}

Si vous passez l'adresse d'un dérivé de B qui n'est pas un D à la procédure f(), le static_cast l 'acceptera (boum!) alors que le dynamic_cast, qui vérifiera à l'exécution si pb est vraiment un D*, retournera 0 (au sens de pointeur nul).

Il faut donc valider, une fois un dynamic_cast appliqué à un pointeur, si le pointeur résultant de cette opération de conversion diffère bel et bien de 0.

Notez que dynamic_cast permet, en situation d'héritage multiple, de réaliser des conversions complexes entre classes soeurs ou cousines.

class B { /* ... */ };
class D0 : public B { /* ... */ };
class D1 : public B { /* ... */ };
class D : public D0, public D1 { /* ... */ };
int main() {
   D0 *pD0 = new D; // légal: un D est un D0 sans ambiguité
   D1 *pD1 = dynamic_cast<D1*>(pD0); // légal: pD0 pointe vers un D qui est
                                     // aussi un D1... dynamic_cast<> navigue
                                     // la hiérarchie du haut vers le bas puis
                                     // du bas vers le haut!
   // ...
}

Notez que dynamic_cast respecte les qualifications d'accès. On ne peut transtyper d'un type S vers un type D si la relation entre ces types n'est pas accessible a priori. Par exemple, dans le cas suivant...

class X {
   // ...
public:
   virtual ~X() = default;
};
class Y {
   // ...
};
class D0 : public X, protected Y {
   // ...
};
class D1 : public X, public Y {
   // ...
};
void f(X *p) {
   Y *q = dynamic_cast<Y*>(p);
   // ...
}
int main() {
   D0 d0;
   D1 d1;
   f(&d0);
   f(&d1);
}

... la raison pour laquelle le transtypage d'un X* en un Y* par f(), une fonction globale, échouera dans le cas où p pointe en fait un D0, est que pour un D0, le parent Y est qualifié protected, donc cette relation n'est connue que de D0, des enfants de D0 et des amis de D0. À moins que f() ne soit friend dans D0, f() n'a pas accès à ce savoir et le transtypage échouera, dans le respect des qualificatifs d'accès.

Par contre, dans le cas où p pointe vers un D1, la conversion sera un succès.

Enfin, s'il y a ambiguïté dans une conversion par voie de dynamic_cast, donc si plus d'un résultat s'avère possible, le transtypage échouera. Par exemple :

class B {
   // ...
public:
   virtual ~B() = default;
};
struct D0 : B {};
struct D1 : B {};
struct D : D0, D1 {};
int main() {
   D d;
   try {
      B & b = dynamic_cast<B &>(d); // oups, ambigu!
   } catch(...) {
      // on passera ici
   }
}

Sémantique d'un dynamic_cast

Quel sens devrait-on donner à un dynamic_cast? Tout dépend s'il est appliqué sur un pointeur ou sur une référence.

class X {
   // ...
public:
   virtual ~X() = default;
};
class Y : public X {
   // ...
};
void f(X *p) {
   Y *q = dynamic_cast<Y*>(p);
   if (q) {
      // utiliser q
   } else {
      // bon, *p n'était pas un Y
   }
}

class X {
   // ...
public:
   virtual ~X() = default;
};
class Y : public X {
   // ...
};
void f(X &p) {
   try {
      Y &q = dynamic_cast<Y&>(p);
      // utiliser q
   } catch(bad_cast&) {
      // bon, p n'était pas un Y
   }
}

Il demeure qu'en pratique, un dynamic_cast dénote habituellement une faute de design. Cherchez à retravailler la structure de vos classes de manière à ne pas avoir à provoquer de tels bris d'encapsulation.

// ...
Y *q = dynamic_cast<Y*>(p);
if (q) {
   // utiliser q
}
// ... ici, q existe encore, mais est-ce pertinent?

// ...
if (Y *q = dynamic_cast<Y*>(p), q) {
   // utiliser q
}
// ... ici, q n'existe plus...

// ...
if (Y *q = dynamic_cast<Y*>(p); q) {
   // utiliser q
}
// ... ici, q n'existe plus...

Source

L'opérateur reinterpret_cast

Sert à produire des conversions de pointeurs (et seulement de pointeurs) un peu moins gentilles et sans la moindre intelligence comme celles d'une donnée du type char* vers le type int* ou entre deux pointeurs de classes qui ne sont pas reliées par une relation de hiérarchie. Ce sont là des conversions qui sont intrinsèquement malsaines, mais parfois nécessaires.

//
// un unsigned int, c'est un peu comme un tableau de sizeof(int) bytes... non?
//
unsigned int conversion_imprudente(char (&arr)[4]) {
   return reinterpret_cast<unsigned int*>(arr+0);
}

L'avantage d'un reinterpret_cast sur son illustre ancêtre (T)e est qu'il est plus visible, et plus facile à isoler.

À vos risques et périls. Sachez reconnaître les moments où cette conversion est nécessaire, et sachez surtout l'éviter le plus possible...

L'opérateur const_cast

Sert à retirer temporairement – et visiblement – une qualification const ou volatile. Pour procéder à un const_cast, il faut que le type de destination soit précisément le type de la source à la qualification const (ou volatile) près.

Cet opérateur peut aussi ajouter la qualification const ou volatile mais est moins utilisé en ce sens du fait que cet ajout tend à être fait de manière implicite.

//
// supposons une fonction comme celle-ci. Le second paramètre, source, est sans danger mais
// n'est malheureusement pas qualifié « const », et on souhaite l'utiliser malgré tout
// car elle s'exécute très rapidement...
//
extern "C" char* strcpy (char*, char*);
//
// prenons soin de l'l'enrober proprement, cependant (question d'hygiène)
// 
inline const char* strcpy(char* dest, const char* source) {
   // appel à la fonction rapide, en cachette. Aussi vite que possible, sans blagues.
   return strcpy(dest, const_cast<char*>(source));
}

Pour comprendre la qualification extern, voir cet article. Ça permet, par exemple, de déclarer une instance d'une classe comme étant const, mais d'utiliser certains de ses membres (de façon ponctuelle, et au risque des programmeuses et des programmeurs, comme dans tout cas de conversion explicite de type) comme n'étant pas const.

Une panacée?

L'insertion de nouveaux opérateurs de conversion explicites de types ne résout pas tous les problèmes et ne blinde pas les programmes contre toute bêtise. C++ permet encore de faire des trucs pas très gentils et plutôt pervers, mais c'est une partie du prix à payer pour avoir un outil aussi polyvalent et puissant.

const char cc = 'a'; // constante de type char
const char* pcc = &cc; // légal
const char **ppcc = &pcc;  // légal
void* pv = ppcc; // légal; eh oui, on peut transtyper implicitement
                 // n'importe quel type de pointeur en void*... mais
                 // on vient de perdre notre const!
char **ppc = (char**)pv; // ouch!
void f() {
   **ppc = 'x'; // BOUM!
}

La prudence reste donc de mise.

Lectures complémentaires

Quelques liens pour enrichir le propos.

• Pour une explication (prudence : ceci date de 1993 alors que les plus récents standards officiels remontent à 1998 – pour lequel il y eut une mise à jour technique en 2003 – et à 2011) des raisons derrière les conversions explicites de types ISO, je vous invite à lire l'article suivant : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0349a.pdf.
• Pour une critique des opérateurs décrits sommairement dans le présent article, voir ce texte de Danny Kalev, en 2007 : http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=285 (on ne peut manifestement pas plaire à tout le monde).
• Texte d'Arne Mertz en 2015 sur la question du transtypage en C++ : http://arne-mertz.de/2015/01/a-casting-show/
• Comparatif de quelques conversions arithmétiques en C++ et en C#, par Ilya Ivanov en 2016 : http://www.viva64.com/en/b/0386/
• En 2017, Andreas Fertig écrit un default_cast qui délègue à la compilation une conversion vers l'un ou l'autre des opérateurs de transtypage : https://www.andreasfertig.blog/2017/10/safer-type-casting-with-c17.html