Un cas classique

class Base
{
  public:
    int x() const { return m_x; }
  protected:
    void set_x(int value) { m_x = value; }
  private:
    int m_x;
};

class Derived : public Base
{
  public:
    void foo() { set_x(5); }
};

Ce code n’évoque probablement rien de nouveau pour la plupart d’entre vous : nous déclarons une classe Base, qui possède une méthode publique, une méthode protégée et une variable membre privée. Nous déclarons également une classe Derived, qui dérive de Base au travers d’un héritage public. Ce principe d’héritage public est généralement simple à comprendre et il est présent dans pratiquement tous les langages objets : lorsque Derived dérive de Base au travers d’un héritage public, on dit aussi que Derived “est un” Base. Toute instance de Derived peut être considérée comme une instance de Base. Comme nous l’avions vu, dans un article précédent, il est également possible de tester si une instance de Base est une instance de Derived grâce à un dynamic_cast<>. De façon résumée, un héritage publique offre les garanties suivantes :

• Toutes les membres (variables et méthodes) publics dans la classe de base le sont aussi dans la classe dérivée.
• Toutes les membres protégés dans la classe de base le sont aussi dans la classe dérivée.
• Les membres privés de la classe de base ne sont pas accessibles à la classe dérivée.
• On peut convertir implicitement un pointeur (respectivement une référence) sur la classe dérivée vers un pointeur (respectivement une référence) sur la classe de base.
• On peut convertir explicitement un pointeur (respectivement une référence) sur la classe de base vers un pointeur (respectivement une référence) sur la classe dérivée.

Ainsi dans notre exemple, Derived peut, dans sa méthode foo() (et indépendamment de la visibilité de cette méthode), appeler la méthode protégée de son parent, set_x(). Elle ne peut pas en revanche, directement accéder à m_x qui est dans une section privée de la classe de base.

Le rôle de l’héritage public

Une concept erroné va généralement de pair avec l’utilisation de l’héritage public : il consiste à dire que ce type d’héritage est utilisé principalement pour favoriser la réutilisation de code. Ceci n’est pas (ou ne devrait pas) être la raison : en C++, il existe beaucoup de moyens de réutiliser son code, la façon la plus efficace étant la composition. Le fait de d’utiliser un héritage public doit être une décision fonctionnelle, et pas une décision technique : ainsi, la classe Table dérive de la classe Meuble parce qu’une table “est un” meuble, et pas parce qu’en faisant ainsi on évite de retaper du code. L’héritage (public ou non) s’il apporte quelque-chose, c’est principalement de la flexibilité.

Bonnes pratiques

Certains auront peut être pensé la chose suivante : “La méthode set_x() ne sert à rien. Autant déclarer m_x protégé directement : il y aura moins de code”. Si cette remarque part surement d’une bonne intention (après tout, avoir moins de code est en général une très bonne idée), elle risque ici d’avoir des conséquences fâcheuses : En procédant de la même façon que dans l’exemple, nous ajoutons certes une méthode, mais nous réduisons également le couplage. En optant pour la solution “simplifiée”, si pour une raison ou pour un autre, je suis amené à modifier l’implémentation de Base et à renommer par exemple m_x en m_first_x, je devrais alors modifier non seulement tout le code de Base mais aussi tout le code de Derived (puisque nous y faisons référence à m_x directement). Le fait d’ajouter une méthode protégée à Base permet de figer son interface “publique” et réduit donc drastiquement le couplage. Il en résulte un code bien plus maintenable. En règle générale, on retiendra que les variables au sein d’une classe seront toujours soit publiques, soit privées, mais très rarement protégées. Et si dans un cas particulier vous sentez avoir vraiment besoin d’un accès à un membre privé, préférez la directive friend qui augmentera bien moins le couplage.

Cette règle n’est évidemment pas absolue et vous risquez de rencontrer un scénario où déclarer une variable membre protégée est la bonne chose à faire. Cependant, ça ne devrait logiquement pas être votre premier réflexe.

L’héritage privé : une alternative à la composition

Qui n’a jamais écrit par erreur, au cours d’une soirée (nuit ?) un peu trop longue quelque-chose de ce genre :

class Derived : Base
{
};

Il en résulte en général de longues minutes très agaçantes où l’on tente de comprendre pourquoi le compilateur refuse systématiquement d’utiliser les variables de la classe parente. La raison est plutôt simple : en l’absence d’un attribut de visibilité, l’héritage par défaut en C++ est privé. Le code précédent est donc équivalent à :

class Derived : private Base
{
};

Voilà une bonne occasion d’expliquer à quoi sert ce type d’héritage. L’héritage privé offre les garanties suivantes :

• Tous les membres publics dans la classe de base sont privés dans la classe dérivée.
• Tous les membres protégés dans la classe de base sont privés dans la classe dérivée.
• Les membres privés de la classe de base ne sont pas accessibles à la classe dérivée.
• La classe dérivée peut redéfinir les méthodes virtuelles de la classe de base.
• Toutes les méthodes de la classe dérivée peuvent convertir un pointeur (respectivement une référence) sur Derived en pointeur (respectivement une référence) sur Base. Ceci n’est en revanche normalement pas possible en dehors de la classe dérivée. (Voir tout de même la remarque).

Là où un héritage public traduit une relation de type “est un”, un héritage privé lui traduit une relation de type “est implémenté en tant que”. En pratique, un héritage privé est comparable à une composition de type 1-vers-1. Prenons un exemple plus parlant :

class Engine
{
  public:
    void start();
};

class Car : private Engine
{
  public:
    using Engine::start;
};

Nous avons déclaré une classe Engine (moteur) et Car (voiture) qui en dérive de façon privée. Dans la déclaration de Car, nous indiquons, au sein d’une section publique et grâce au mot clé using, que nous utilisons la méthode start() de la classe parente. Celle-ci devient donc publique pour la classe fille et en dehors. Dans ce cas, on voit bien qu’un héritage public n’aurait aucun sens puisqu’une voiture “n’est pas” un moteur, elle “possède un moteur”. Certains se demandent peut être si une composition n’est pas plus indiquée dans ce cas et la réponse n’est pas évidente :

• En règle générale, oui, préférez la composition à l’héritage…
• … mais dans le cas que nous présentons ici, la composition est assez “forte” : une voiture ne peut toujours avoir qu’un seul moteur, et le fait de démarrer la voiture revient à démarrer le moteur.

Les cas où l’on peut légitimement accepter un héritage privé en lieu et place d’une composition restent très limités. Et personne ne vous blâmera si même dans ce cas, vous optez pour la composition. L’héritage privé est surtout une facilité du langage pour éviter au programmeur de saisir du code inutile : dans notre exemple, en utilisant une composition, on aurait obtenu quelque-chose de ce genre :

class Engine
{
  public:
    void start();
};

class Car
{
  public:
    void start() { m_engine.start(); }
  private:
    Engine m_engine;
};

Pas vraiment plus difficile à comprendre, mais un peu plus long à taper. Et si ce n’était pas une mais vingt méthodes de Engine qu’il avait fallu “transporter” dans l’interface publique de Car, je vous laisse imaginer le temps perdu à saisir toutes les méthodes triviales qui ne font qu’appeler la “vraie” méthode du sous-objet. Dans tous les cas, notez qu’en t’en qu’utilisateur de la classe Car, vous ne devez jamais prendre en compte la présence d’un héritage privé dans sa définition : cet héritage est privé et relève de l’implémentation : l’auteur de la classe peut à tout moment décider de réécrire sa classe pour utiliser une composition classique, ou encore de redéfinir à la main chacune des méthodes, sans vous en notifier !

Remarque

Un lecteur assidu aura peut être remarqué une contradiction avec un de mes articles précédents : en effet, si j’ai indiqué un peu plus haut qu’il n’était pas possible de convertir un Car* en Engine* en dehors des méthodes de Car, ce n’était pas tout à fait vrai : cela est possible en C++, par l’intermédiaire d’une “conversion à la façon C”. Évidemment, si on respecte la clause énoncée précédemment de ne jamais se baser sur le détail d’implémentation que représente l’héritage privé, il ne s’agit en fait que d’un argument supplémentaire contre l’utilisation de ce type de conversion. En un mot : faites-le une fois pour vous amuser, puis plus jamais !

À propos du mot clé using

S’il est très courant de rencontrer le mot clé using lors de l’utilisation d’héritage privé, il est également possible de l’utiliser lors d’un héritage “classique” public :

class Base
{
  public:
    int x() const { return m_x; }
  protected:
    void set_x(int value) { m_x = value; }
  private:
    int m_x;
};

class Derived : public Base
{
  public:
    using Base::set_x;
};

Ici, nous avons augmenté la visibilité de la méthode set_x() en la rendant publique dans la classe dérivée, alors qu’elle n’était que protégée dans la classe de base. Bien que peu courante, cette syntaxe n’en demeure pas moins tout à fait correcte.

L’héritage protégé

L’héritage protégé ressemble énormément à l’héritage privé. En fait, sa seule différence est la suivante :

• Tout membre public ou protégé hérité au travers d’un héritage protégé est également accessible de façon protégée aux classes filles de la classe dérivée.

Ce qui se traduit par :

class Engine
{
  protected:
    void start() {};
};

class Car : protected Engine {};

class Robot : protected Car
{
  public:
    using Engine::start;
};

Ici Robot peut accéder à la méthode protégée de Engine parce que Car hérite de Engine au travers d’un héritage protégé. On voit que si l’héritage privé peut s’avérer utile dans certains cas, l’héritage protégé lui a un intérêt beaucoup plus limité, car le fait de pouvoir accéder aux méthodes de sa classe grand-parente ne fait qu’augmenter le couplage.

Je n’ai encore jamais rencontré ou eu besoin d’un héritage protégé depuis que je développe en C++.

L’héritage virtuel

Pour expliquer en quoi consiste l’héritage virtuel, replaçons avant tout dans le contexte quelques lieux communs :

L’héritage multiple

C++ est l’un des rares langages à autoriser l’héritage multiple là où les autres langages préfèrent imposer la notion d’interfaces. La légitimité de l’une ou de l’autre de ces techniques est un sujet à part entière et sort du cadre de cet article. Si vous vous intéressez à ce débat, il existe sur l’Internet bien des discussions à ce sujet.

La minute “rebelle”

Vous avez certainement déjà entendu quelqu’un dire une chose du genre : “L’héritage multiple c’est toujours une hérésie, ça n’aurait jamais du exister ! Je n’ai jamais réussi à en faire quoi que ce soit d’utile.”

Face à ce genre de remarque simpliste, j’ai tendence à avoir la même réaction que Marshall Cline : les gens qui vous disent ça ne connaissent à priori pas votre problème ou vos besoins, et pourtant ils prétendent y répondre : comment le pourraient-ils ? Comment peuvent-ils savoir que dans votre situation, l’héritage multiple n’est pas la meilleure solution ? Si vous rencontrez ce genre de personnes, soyez prudents : le manque d’ouverture d’esprit et de réflexion fait en général de bien piètres programmeurs. Une phrase que j’aime bien citer dans cette situation est celle-ci : “Toutes les phrases qui dénoncent un principe de façon absolue et générale sont absolument et généralement fausses”. Si l’héritage multiple semble être la solution à votre problème, n’hésitez pas à l’utiliser.

Dans tous les cas, réfléchissez toujours bien à ce que vous faites : si l’héritage multiple est tant victime d’à priori négatifs, c’est qu’il est parfois difficile de comprendre son utilisation.

La démonstration par l’exemple

Pour illustrer les notions d’héritage multiple et virtuel, créons tout d’abord une hiérarchie de classes :

Hiérarchie de classe à héritage multiple

Comme nous le voyons ici, nous partons d’une classe Shape (“forme” en anglais), de laquelle dérivent deux classes Rectangle et Diamond (“losange” en anglais). Une quatrième classe, Square (“carré” en anglais) hérite à la fois de Rectangle et de Diamond.

Une implémentation naïve de cette hiérarchie en C++ pourrait ressembler à :

class Shape
{
  public:
    int identifier() const { return m_identifier; }
    virtual void draw() = 0;
  private:
    int m_identifier;
};

class Rectangle : public Shape
{
  public:
    void draw() { /* ... */ }
};

class Diamond : public Shape
{
  public:
    void draw() { /* ... */ }
};

class Square : public Rectangle, public Diamond
{
  public:
    void draw() { /* ... */ }
};

Cela a du sens : un carré (si on s’en réfère aux lois de la géométrie) est à la fois un rectangle et un losange, et il est aussi une forme.

Cependant, ce code n’a en pratique pas la structure souhaitée :

En effet, en utilisant un héritage classique (non virtuel) Square hérite en pratique deux fois de Shape : une fois par la branche de gauche (Rectangle), et une fois par la branche de droite (Diamond). Il en résulte que chaque instance de Square possède deux instances de m_identifier. Lorsqu’on souhaite utiliser identifier() ou m_identifier dans ou en dehors de la classe Square, il faut préciser par quelle branche on passe :

• Soit en préfixant m_identifier par Diamond ou Rectangle (“Rectangle::m_identifier“);
• soit en effectuant auparavant une conversion de this vers Rectangle* ou Diamond* (“static_cast(this)->m_identifier“)

Ce n’est généralement pas ce qui est souhaité.

Pour résoudre ce problème, nous avons besoin de l’héritage virtuel :

class Shape
{
  public:
    int identifier() const { return m_identifier; }
    virtual void draw() = 0;
  private:
    int m_identifier;
};

class Rectangle : public virtual Shape // Notez la présence de "virtual" ici
{
  public:
    void draw() { /* ... */ }
};

class Diamond : public virtual Shape // Notez la présence de "virtual" ici
{
  public:
    void draw() { /* ... */ }
};

class Square : public Rectangle, public Diamond
{
  public:
    void draw() { /* ... */ }
};

En spécifiant que Rectangle et Diamond héritent tous deux virtuellement de Shape, nous empêchons la multiple instanciation du type de base : il n’y a alors plus qu’une seule instance de m_identifier et on peut y référer directement sans avoir recours à des conversions.

Bonnes pratiques

L’utilisation de l’héritage virtuel peut se faire conjointement avec tout autre type d’héritage (privé, protégé et public), mais est habituellement rencontré principalement avec l’héritage public.

Indépendamment de l’utilisation de l’héritage virtuel, on constate assez logiquement que les classes les plus en haut de la hiérarchie devraient dans l’idéal être virtuelles pures. Si c’est le cas, cela ne signifie pas forcément qu’il faille supprimer l’héritage virtuel : outre le fait de ne pas dupliquer inutilement les instances des membres, l’héritage virtuel permet également de s’assurer que la classe de base n’a qu’une seule adresse dans les instances filles. Il est en pratique très probable que vous deviez user d’héritage virtuel lorsque vous utilisez l’héritage multiple.

Conclusion

Nous avons vu au travers des différentes sections que C++ est très complet en matière d’héritage. Élément incontournable de la programmation orientée objet moderne, c’est un principe qu’il convient de manier avec la plus grande précaution et une bonne réflexion : si l’héritage peut résoudre bien des problèmes, il n’est de loin pas la solution universelle. Que vous optiez pour l’héritage, la composition ou autre chose pour la résolution de vos problèmes, réfléchissez toujours et envisagez chacune des possibilités.

Comme toujours, n’hésitez pas à me faire part de vos remarques, questions ou corrections dans les commentaires.

Sources

Voici une série de liens en anglais qui m’ont inspiré pour la rédaction de cet article. N’hésitez pas à les consulter, ils sont extrêmement intéressants :

• L’héritage privé/protégé sur parashift
• StackOverflow
• L’héritage virtuel sur allexperts
• L’héritage virtuel sur parashift

Parmi ces différences, on trouve les opérateurs de conversion C++. Ils sont certainement l’un des points les plus mal compris par les développeurs C qui voient souvent en eux un verbiage inutile. L’objectif de cet article est de (dé)montrer l’utilité des opérateurs de conversion C++, en comparaison avec les conversions classiques, dites : “à la C” et de comprendre ce qu’ils peuvent apporter au programmeur en termes de maintenabilité et de sécurité.

Un petit mot sur les conversions

Les conversions (ou “cast” en anglais) sont un des outils incontournables du programmeur C++. Mais comme tout outil, il faut savoir les utiliser à bon escient.

Dans l’idéal, un programme doit contenir le moins possible de “casts” : les types doivent s’interfacer naturellement les uns avec les autres. Cela garantit un découplage du code et donc une meilleure maintenabilité. Cela ne signifie pas qu’il faille à tout prix éviter les “casts” mais simplement qu’il faut les utiliser avec parcimonie.

Dans les sections qui suivent, nous allons expliquer le rôle de chaque opérateur de conversion. Pour l’ensemble des sections, nous considérerons les classes suivantes lorsqu’il sera question de hiérarchie :

class Base { public: virtual ~Base() {} };
class Derived : public Base {};
class Derived2 : public Base {};

static_cast<>

Il permet plusieurs choses :

• Expliciter les conversions implicites, supprimant du même fait tout avertissement que donnerait le compilateur si la conversion peut entraîner un risque. Exemple : double vers int.
• Convertir vers et depuis n’importe quel type pointé à partir d’un void*. Exemple : void* vers unsigned char*.
• Convertir au travers d’une hiérarchie de classe, sans effectuer de vérification préalable. Exemple : Base* vers Derived* ou Base& vers Derived&.
• Ajouter l’attribut constant au type converti. Exemple : char* vers const char*.

Dans le dernier cas, notez que puisqu’il n’y a aucune vérification et que static_cast<> n’échoue jamais, le code suivant a un comportement indéfini (communément nommé en anglais “undefined behavior” ou “UB“) :

void foo()
{
Base* base = new Derived();

// Ce code est valide et correct car base pointe en fait vers une instance de Derived.
Derived* derived = static_cast<Derived*>(base);

// Ce code compile mais à un comportement indéfini (Undefined Behavior)
// car base ne pointe pas vers une instance de Derived2.
Derived2* derived2 = static_cast<Derived2*>(base);
}

Notez que la notion de comportement indéfini n’offre par définition aucune garantie : le code peut avoir le comportement espéré, faire crasher le programme ou provoquer l’envoi d’un missile nucléaire sur Cuba.

Il ne permet pas de :

• Convertir vers ou depuis un type pointé à partir d’un autre type pointé autre que void*. Exemple : unsigned char* vers char*.
• Tester qu’une instance est celle d’un type dérivé. Exemple : tester qu’un Base* est en fait un Derived*.
• Supprimer l’attribut constant du type converti. Exemple : const char* vers char*.

En bref

static_cast<> est sans doute l’opérateur de conversion que vous serez amené à utiliser le plus. Il ne permet que de réaliser des conversions sûres et à pour rôle principal celui d’expliciter les conversions implicites.

Dans le cas du polymorphisme, il est à préférer à dynamic_cast<> lorsque l’on a la garantie que la conversion va réussir.

dynamic_cast<>

Le seul rôle de dynamic_cast<> est de tester à l’exécution si un pointeur d’un type de base est en fait un pointeur vers un type dérivé.

Exemple :

void foo()
{
Base* base = new Derived();

// Après l'appel, derived pointe vers l'instance de Derived
// car base pointe en fait vers une instance de Derived.
Derived* derived = dynamic_cast<Derived*>(base);

// Après l'appel, derived2 vaut 0
// car base ne pointe pas vers une instance de Derived2.
Derived2* derived2 = dynamic_cast<Derived2*>(base);

// Dans le cas d'une référence, si le cast n'est pas possible
// Une exception de type std::bad_alloc est lancée.
Derived2& derived2_bis = dynamic_cast<Derived2&>(*base);
}

Note : pour que dynamic_cast<> fonctionne, le type de base doit posséder au moins une méthode virtuelle.

Un appel à dynamic_cast<> est plus coûteux qu’un appel à static_cast<>car dynamic_cast<> effectue une recherche dans la “v-table” de l’instance à l’exécution pour déterminer son type exact.

On veillera donc à n’utiliser dynamic_cast<> que lorsqu’il n’y a aucune autre solution.

En bref

dynamic_cast<> est le seul opérateur de conversion à avoir un effet “indéterminé” jusqu’à l’exécution. Son utilisation n’a de sens que lorsque confronté à du polymorphisme. Dans les cas où la conversion est assurée de réussir, on lui préfèrera static_cast<> plus rapide et ne nécessitant pas que les classes possèdent une méthode virtuelle.

const_cast<>

const_cast<> permet de supprimer l’attribut constant ou volatile d’une référence ou d’un type pointé. Exemple : const char* vers char* ou volatile int vers int.

C’est notamment le seul opérateur de conversion à pouvoir le faire : même reinterpret_cast<> n’a pas ce pouvoir.

void foo()
{
char* buf = new char[16];

// L'ajout de l'attribut const ne nécessite pas de cast
// Il est implicite
const char* cbuf = buf;

// Le retrait de l'attribut const nécessite const_cast<>.
char* buf2 = const_cast<char*>(cbuf);
}

L’importance d’écrire un code “const-correct”

Directement relié aux opérateurs de conversion, l’écriture d’un code const-correct est un autre aspect du C++ souvent mal perçu par les programmeurs C. Le C est plus ancien et le mot clé const n’y a pas toujours existé; il a été emprunté au C++ par la suite.

Le fait d’indiquer qu’une variable est constante est un outil puissant permettant au compilateur de nous signaler certaines de nos erreurs qui auraient autrement passé la barrière de la compilation.

Qui ne s’est jamais trompé dans l’ordre des arguments d’un memcpy() ?

void foo()
{
const char* source = "blog.freelan.org";
char* destination = new char[16];

// Oups ! Je me suis trompé dans l'ordre des arguments...
// ... heureusement, puisque memcpy spécifie que le premier paramètre est un void*
// et pas un const void*, le compilateur m'indique une erreur.
memcpy(source, destination, strnlen(source));
}

Les mots clé “const” ou “volatile” appliqués aux classes

En C++, les mots clé const et volatile s’appliquent évidemment aussi aux instances de classes mais ont des sémantiques différentes :

Le caractère const ou volatile s’applique récursivement aux membres de l’instance.

Il n’est possible d’appeler une méthode d’une classe que dans les cas suivants :

• l’instance n’est pas const.
• l’instance est const et la méthode est déclarée const.
• l’instance est déclarée volatile et la méthode est déclarée volatile.
• l’instance est déclarée const et volatile et la méthode est elle aussi déclarée const et volatile.

À propos de “volatile”

Certains lecteurs peuvent être perdus à la lecture du mot clé volatile qui, il faut bien l’avouer, n’est pas utilisé très souvent. Décrire précisément le rôle de volatile mériterait un article bien à part mais je vais tout de même dire en deux mots à quoi il sert :

Lorsqu’une variable est déclarée volatile, le compilateur n’a pas le droit d’optimiser sa valeur (mise en cache processeur) lors de tests.

Ainsi sans volatile sur la variable do_loop, le code suivant :

void foo()
{
bool do_loop = true;
while (do_loop) { doSomething(); }
}

Risquerait d’être optimisé en tant que :

void foo()
{
while (true) { doSomething(); }
}

Ce qui est correct dans la plupart des cas… sauf si do_loop peut être modifié par un autre thread. C’est principalement dans ce genre de cas que volatile trouve son utilité.

Erreurs courantes

Une erreur courante concernant const_cast<> consiste à supposer que l’on peut toujours supprimer le caractère constant d’une variable.

Ceci est évidemment faux : on ne peut supprimer le caractère constant (respectivement volatile) d’une variable que lorsque celle-ci a été déclarée non-const (respectivement non-volatile).

Ainsi le code suivant a un comportement indéfini :

void foo()
{
const char* cbuf = "blog.freelan.org";

// L'utilisation de const_cast<> ici a un comportement indéfini (undefined behavior)
// car cbuf a été déclaré const.
char* buf = const_cast<char*>(cbuf);
}

Un autre cas courant est celui des variables membres qui servent à mettre en cache un résultat :

class MyClass
{
public:

MyClass() : m_value_cache(0) {}

int getValue() const
{
if (m_value_cache == 0)
const_cast<int&>(m_value_cache) = computeValue();

return m_value_cache;
}

private:

static int computeValue();

int m_value_cache;
};

L’utilisation de const_cast<> ici est erronée : si on déclare une instance const de MyClass, m_value_cache est aussi const lors de sa définition. L’utilisation de const_cast<> est la même que dans l’exemple précédent et a comportement indéfini.

La bonne solution est d’utiliser le mot clé mutable, qui permet à une variable membre de ne pas avoir les mêmes contraintes const/volatile que son instance parente :

class MyClass
{
public:

MyClass() : m_value_cache(0) {}

int getValue() const
{
// m_value_cache est déclaré mutable
// il peut donc changer, même dans une méthode const
if (m_value_cache == 0)
m_value_cache = computeValue();

return m_value_cache;
}

private:

static int computeValue();

// Utilisation du mot clé "mutable"
mutable int m_value_cache;
};

En bref

const_cast<> est le seul opérateur de conversion à pouvoir supprimer le caractère const ou volatile d’une variable. L’utilisation de const_cast<> doit rester très rare : le contraire indique souvent une importante erreur de design. Son seul usage habituellement toléré est l’interfaçage avec des bibliothèques historiques qui ne sont pas const-correct.

reinterpret_cast<>

Il s’agit de l’opérateur de conversion le plus dangereux, et du plus mal utilisé. Son rôle est de dire au compilateur : “réinterprète-moi la représentation binaire de ce type en tant qu’un autre type”.

Il permet :

• De convertir n’importe quel type pointé en une autre, même lorsque ceux-ci n’ont aucun rapport. Exemple : int* vers double*.
• De convertir un type pointé en sa représentation intégrale et vice et versa. Exemple : int* vers int.

Il est à noter que ces conversions sont dépendantes de l’implémentation. En d’autres termes, le compilateur est libre de faire ce qu’il veut concernant la conversion basée sur reinterpret_cast<> mais ce comportement doit être constant : il ne s’agit pas de comportement indéfini; le comportement est bien défini, simplement pas par le standard C++ mais votre version du compilateur. Si vous vous basez sur cette dépendance de l’implémentation, votre code est donc non-portable.

La seule garantie délivrée par le standard C++ concernant reinterpret_cast<> est que si vous convertissez un type A en un type B, puis de nouveau en un type A, le comportement est bien défini et vous récupérez bien la valeur de départ.

On comprend dès lors facilement le danger que peut représenter reinterpret_cast<>.

Voici un exemple d’utilisation :

void foo()
{
int a = 5;

// Le contenu de b dépend du compilateur utilisé
// et n'est pas défini par le standard
double* b = reinterpret_cast<double*>(&a);

// Ici, on a la garantie que *c vaudra a, c'est à dire 5.
int* c = reinterpret_cast<int*>(b);
}

Cas particuliers

Le peu de garanties associées à reinterpret_cast<> rendent celui-ci quasiment inutile dans la plupart des cas. Il y a cependant certaines exceptions de fait qui justifient une utilisation de reinterpret_cast<> sans nuire à la portabilité :

Les conversions entre les types char* et unsigned char* bien que non spécifiées par le standard, sont en pratique supportées par tous les compilateurs et produisent le comportement attendu. Le compilateurs ont par ailleurs de plus fortes contraintes à leur égard (spécifiquement au niveau de leur représentation) pour des raisons de compatibilité ascendante avec le C.

Vous pouvez donc clairement supposer qu’un reinterpret_cast<> entre un char* et un unsigned char* sera à la fois portable et défini.

Polymorphisme

reinterpret_cast<> utilisé dans le cadre d’une conversion faisant intervenir du polymorphisme a un comportement non défini. Il n’est ainsi pas correct d’effectuer un reinterpret_cast<> entre par exemple un Base* et un Derived*.

En bref

reinterpret_cast<> est l’opérateur de conversion le plus dangereux : permettant de faire ce qu’aucun autre ne peut faire (des conversions entres des types non liés) il convient de l’utiliser avec la plus grande prudence. En pratique, on lui préfèrera static_cast<> qui permet d’effectuer des conversions plus sûres, y compris vers et depuis des types pointés génériques (void*). Son seul usage toléré est l’interfaçage avec du code C ancien qui utilise pour ses paramètres de “buffer” des char* ou unsigned char* au lieu des void*.

Old-school : les conversions “à la C”

Le C++ supporte toujours l’ancienne syntaxe concernant les conversions “à la façon C”. Cependant, le standard précise clairement l’effet d’une telle conversion :

Le “cast” suivant : (Type)valeur ou Type(valeur)

Sera équivalent à, par ordre de préférence :

1. un const_cast<>
2. un static_cast<>
3. un static_cast<> suivi d’un const_cast<>
4. un reinterpret_cast<>
5. un reinterpret_cast<> suivi d’un const_cast<>

Les bonnes pratiques indiquent souvent que l’utilisation de ce type de conversion est à bannir, principalement parce qu’il peut résulter silencieusement en un reinterpret_cast<>, qui comme nous l’avons vu, peut se révéler extrêmement dangereux. De plus, l’usage des alternatives modernes aux opérateurs de conversion permet de spécifier clairement l’intention du programmeur et de protéger contre les erreurs involontaires (comme celles que nous avons vu avec const_cast<>).

Une autre utilité

Les “casts” à la C offrent également une possibilité qui n’est permise par aucun autre opérateur de conversion : celle de convertir vers une classe de base au travers d’un héritage privé. Ce type d’héritage est très souvent critiqué et fortement déconseillé. Je ne détaillerai pas ici les conséquences et les raisons de ce type d’héritage; c’est un sujet qui mérite son propre article.

Conclusion

Il y a beaucoup à dire sur les opérateurs de conversion et encore plus à apprendre. Nous avons vu que bien utilisés, ils sont un outil puissant et un allié du programmeur. Protégeant contre les erreurs involontaires et révélant les erreurs de conception, ils restent pour certains dangereux et sont tout de même à utiliser avec la plus grande précaution.

Une bonne connaissance de ces opérateurs de conversion et de leurs limites reste indispensable à la réalisation de programmes maintenables en C++.

Références

Voici une série de liens (en anglais, pour la plupart) qui m’ont inspiré dans la rédaction de cet article.

• http://stackoverflow.com/questions/28002/regular-cast-vs-static-cast-vs-dynamic-cast
• http://stackoverflow.com/questions/332030/when-should-static-cast-dynamic-cast-and-reinterpret-cast-be-used
• http://stackoverflow.com/questions/4708444/is-there-a-good-way-to-convert-from-unsigned-char-to-char
• http://msdn.microsoft.com/en-us/library/5f6c9f8h%28v=VS.80%29.aspx

N’hésitez pas à les consulter pour obtenir d’autres informations. Je vous recommande également de vous inscrire sur Stack Overflow qui est à mon sens le meilleur site de questions/réponses concernant la programmation : le niveau des questions et surtout des réponses y est vraiment très élevé.

Comme toujours bien sûr, vous pouvez également utiliser les commentaires pour obtenir des précisions sur un point ou l’autre.

Merci pour votre lecture !