LE C++ POUR LES PROS

Le constructeur par défaut est un constructeur sans argument ou dont chacun des arguments possède une valeur par défaut.

Il est utilisé, par exemple, lorsque l'on crée des tableaux d'objet. En effet, il n'est pas possible de passer un constructeur à l'opérateur new[] responsable de la création des tableaux.

En outre, de nombreuses bibliothèques commerciales ou non (Third Party Software), dont la bibliothèque standard du C++, nécessitent un constructeur par défaut pour la fabrication d'objets temporaires.

Si vous ne spécifiez aucun constructeur pour votre classe, alors le compilateur essaye de fournir un constructeur par défaut, qui, selon les environnements de développement, initialise à zéro chacun des membres de la classe ou les laisse vides. Au cas où votre classe agrégerait par valeur des objets, ceux-ci sont initialisés par leur constructeur par défaut s'il existe - autrement, le constructeur par défaut automatique ne peut pas être construit faute de moyen de construction des objets agrégés.

À partir du moment où vous spécifiez au moins un constructeur pour votre classe, le compilateur n'essaie plus de générer de constructeur par défaut automatique considérant que ceci est de votre ressort. De manière générale, il est très dangereux de ne pas fournir de constructeur pour une classe, sauf, peut-être, dans le cas de classes exception sans attribut.

Le Programme 1.2 montre un exemple où il est nécessaire de fournir un constructeur par défaut à la classe Toto.

class Toto
{
    private:
        // declarations sans intérêt
    public:
        // Toto(int i); // Constructeur
};
 
int main(int, char**)
{
    Toto tableau[3];     // Erreur !
                        // il faudrait un
                        // constructeur par
                        // défaut !
}
 
 
class Toto
{
    private:
        // declarations sans intérêt
    public:
        // Toto(int i=3);     // Constructeur
        // par défaut !
};
 
int main(int, char**)
{
    Toto tableau[3];     // Correct !
                        // tous les objets
                        // sont construits
                        // avec la valeur 3
}

I-B-1. But du constructeur de recopies▲

I-B-2. Prototype du constructeur de recopie▲

        T::T(const T&)

I-B-3. Quand est il nécessaire de créer un constructeur de recopie ?▲

Le destructeur est là pour rendre les ressources occupées par un objet lorsqu'il arrive en fin de vie, soit qu'il soit alloué statiquement et sorte de portée, soit qu'il ait été alloué dynamiquement à l'aide de new et qu'on lui applique delete pour le supprimer.

Si un objet agrège statiquement d'autres objets, ceux-ci sont automatiquement détruits : il n'y a pas lieu de s'en soucier.

En revanche, s'il agrège dynamiquement d'autres objets (en particulier par l'intermédiaire de pointeurs), il sera indispensable de les détruire (par un appel à delete) sous peine de ne pouvoir disposer à nouveau de la mémoire avant le prochain reboot !

Pour conclure sur le destructeur, celui-ci sera nécessaire dès lors que votre classe réalise de l'agrégation par pointeur ou de l'allocation dynamique de mémoire.

L'opérateur d'affectation est utilisé pour dupliquer un objet dans un autre en dehors des déclarations où ce rôle est dévolu au constructeur de recopie. De fait, il est nécessaire de créer un opérateur lorsqu'il est nécessaire de créer un opérateur de recopie : agrégation et allocation dynamique de mémoire ; dans tous les autres cas, le compilateur crée pour vous un opérateur d'affectation « par recopie bit à bit optimisée » qui frôle la perfection.

L'opérateur d'affectation est utilisé pour dupliquer un objet dans un autre en dehors des déclarations où ce rôle est dévolu au constructeur de recopie. De fait, il est nécessaire de créer un opérateur lorsqu'il est nécessaire de créer un opérateur de recopie : agrégation et allocation dynamique de mémoire ; dans tous les autres cas, le compilateur crée pour vous un opérateur d'affectation « par recopie bit à bit optimisée » qui frôle la perfection.

I-D-1. Prototype de l'opérateur d'affectation▲

T& T::operator=(const T&)

I-D-2. Difficulté supplémentaire par rapport au constructeur par▲

Appliquons les principes précédents à la constitution d'une chaine de caractères mise sous forme canonique de Coplien.

I-E-1. Structure :▲

I-E-2. Mise en œuvre▲

Voici l'implémentation finale de notre classe chaine. Bien entendu, la forme canonique ne fournit que le canevas de base nécessaire à une utilisation rationnelle de la mémoire qui ne comprend pas les méthodes nécessaires au bon fonctionnement de la chaine.

#ifndef __Chaine_H__
#define __Chaine_H__
#include <string.h>
 
class Chaine
{
    private:
        int capacite_;
        int longueur_;
        char *tab;
        enum {CAPACITE_DEFAUT=16}; // Capacité par défaut
                                   // et granularité d'allocation
    public:
        // constructeur par défaut
        Chaine(int capacite=CAPACITE_DEFAUT) :
        capacite_(capacite),
        longueur_(0)
    {
        tab=new char[capacite_];
        tab[0]=0;
    }
    // second constructeur
    Chaine(char *ch)
    {
        int lChaine=strlen(ch);
        int modulo=lChaine % CAPACITE_DEFAUT;
        if (modulo)
            capacite_=((lChaine / CAPACITE_DEFAUT)+1)*CAPACITE_DEFAUT;
        else
            capacite_=lChaine;
        longueur_=lChaine;
        tab=new char[capacite_];
        strcpy(tab,ch);
    }
 
    // constructeur par recopie
    Chaine(const Chaine &uneChaine) :
        capacite_(uneChaine.capacite_),
        longueur_(uneChaine.longueur_)
    {
        tab=new char[capacite_];
        strcpy(tab, uneChaine.tab);
    }
 
    // accès aux membres
    int capacite(void)
    {
        return capacite_;
    }
 
    int longueur(void)
    {
        return longueur_;
    }
 
    // destructeur
    ~Chaine(void)
    {
        if (tab)
            delete [] tab; // ne jamais oublier les crochets lorsque
                            // l'on désalloue un tableau !
    }
 
    // Operateur d'affectation
    Chaine & operator=(const Chaine& uneChaine)
    {
        if (tab == uneChaine.tab)
            return (*this);
 
        if (tab)
            delete [] tab;
        capacite_=uneChaine.capacite_;
        longueur_=uneChaine.longueur_;
        tab = new char[capacite_];
        strcpy(tab,uneChaine.tab);
        return *this;
    }
};
#endif

Énoncé :

Décrivez lignes de code suivantes (mettant en jeu les classes T et U) en séparant éventuellement les cas T=U et T/=8

1) T t;
2) U u;
3) T z(t);
4) T v();
5) T y=t;
6) z = t;
7) T a(u);
8) t = u;

Correction :

T t Construction d'un objet t de classe T avec appel du constructeur par défaut

U u Construction d'un objet u de classe U avec appel du constructeur par défaut

T z(t) Construction d'un objet z de classe T avec appel du constructeur de recopie sur l'objet t

T v() Déclaration d'une fonction v renvoyant un objet de classe T et ne prenant pas de paramètre.

T y=t Construction d'un d'objet y de classe T avec appel du constructeur de recopie sur l'objet t. Il ne peut en aucun cas s'agir d'une affectation, car nous sommes dans une déclaration et l'objet y doit être construit ! En fait les lignes 3 et 5 sont équivalentes

z = t Affectation de l'objet t à l'objet z par l'opérateur d'affectation. Nous sommes bien ici dans le cadre d'une affectation : les objets t et z sont déjà construits et la ligne de code n'est pas une déclaration

T a(u) Dans le cas général (T/=8 il s'agit de la construction d'un objet de classe T à partir d'un objet de classe U à l'aide d'un constructeur de la forme T(const U&). Dans le cas dégénéré (T=U), il s'agit d'un appel au constructeur de recopie.

t = u Dans le cas général (T/=8 il s'agit de l'affectation d'un objet de classe U à un objet de classe T à l'aide d'un opérateur de la forme T& operator=(const U&). Dans le cas dégénéré (T=U), il s'agit d'une affectation à l'aide de l'opérateur d'affectation de la forme canonique.

Bien que ce dernier propos soit détaché de la librairie standard du C++, je crois bon de rappeler que les constructeurs ne supportent pas le polymorphisme. En particulier, il est impossible d'appeler automatiquement depuis le constructeur de la classe de base une méthode polymorphique.

Considérons par exemple le code suivant :

#include <iostream.h>
 
class T1
{
    public:
        virtual void afficher(void)
    {
        cout << "Classe T1" << endl;
    }
    T1(void)
    {
        afficher();
    }
    virtual ~T1()
    {
        cout << "On detruit T1" << endl << "Affichage ";
        afficher();
    }
};
 
class T2 : public T1
{
    public:
        virtual void afficher(void)
    {
        cout << "Classe T2" << endl;
    }
    T2(void) : T1()
    {
    }
 
    virtual ~T2()
    {
        cout << "On detruit T2" << endl << "Affichage ";
        afficher();
    }
};

Le but ici est d'appeler la méthode afficher spécifique à chaque classe à l'intérieur de son constructeur. De même, on réalise la même opération à l'intérieur du destructeur.

Voici la fonction main associée :

int main(int, char**)
{            
    cout << "Avant la construction d'un objet de classe T1" << endl;
    T1 t1;
    cout << "Avant la construction d'un objet de classe T2" << endl;
    T2 t2;
    return 0;
}

On s'attendrait donc à un résultat du style :

Avant la construction d'un objet de classe T1
Classe T1
Avant la construction d'un objet de classe T2
Classe T2
On detruit T2
Affichage Classe T2
On detruit T1
Affichage Classe T1
On detruit T1
Affichage Classe T1

Or, le résultat obtenu est le suivant :

Avant la construction d'un objet de classe T1
Classe T1
Avant la construction d'un objet de classe T2
Classe T1
On detruit T2
Affichage Classe T2
On detruit T1
Affichage Classe T1
On detruit T1
Affichage Classe T1

Le verdict est simple : le constructeur de T1 appelle toujours la méthode T1::afficher et n'applique pas le polymorphisme alors que le destructeur qui lui, est une méthode d'instance virtuelle le fait sans problème ! Ceci s'explique en fait très simplement : lors de la construction d'un objet de classe T1 par son constructeur la table des méthodes virtuelles n'est pas encore affectée à l'objet et les différentes méthodes appelées le sont toujours par liaison statique. C'est à la sortie du constructeur que la table des méthodes virtuelles est opérationnelle.

Bien entendu, il s'agit là d'un exemple d'école, mais bien des personnes tentaient d'appeler une méthode d'initialisation automatique polymorphique des attributs à des valeurs par défaut de cette manière. Je vous laisse augurer de leur déception !

La surcharge des opérateurs standard est assurément l'une des fonctionnalités de C++ les plus appréciées. En effet, il est indubitable que cela permet d'écrire du code ayant un aspect très naturel.

Or, leur écriture est très piégeuse. En effet, certains doivent être surchargés en tant que fonctions, d'autres en tant que méthodes, leur type de retour doit être soigneusement étudié etc.

Il n'est donc pas inutile d'y revenir quelque peu !

Comment choisir si l'on doit définir un opérateur surchargé en tant que méthode ou bien en tant que fonction externe à la classe ?

II-B-1. Un exemple particulier : les opérateurs de redirection▲

class T
{
    public:
        ostream &operator<<(ostream &a)
    {
        // code omis ...
        return a;
    }
};

T t;

t.operator<<(cout);

T << cout;

II-B-2. Une règle bien utile▲

T& T::operator=(const T&a)

T T::operator+(const T&a)

T ::operator+(const T&a, const T&b)

II-B-3. Récapitulatif▲

Pour commencer, il faut savoir que certains opérateurs ne peuvent pas être redéfinis, car le langage vous l'interdit ! Il s'agit de

Tableau 2.2 Opérateurs du C++ ne pouvant être surchargés

Vous noterez au passage, que si la sélection d'un membre d'un objet statique par l'opérateur . ne peut être surchargée, en revanche la sélection d'un membre d'un objet dynamique par l'opérateur flèche -> peut, elle, l'être ! Cela permettra, par exemple de créer des classes de pointeurs intelligents.

En outre, même si vous en avez la possibilité, il vaut mieux ne pas surcharger les opérateurs suivants :

Tableau 2.3 Opérateurs C++ qu'il vaut mieux ne pas surcharger

En effet, il faut respecter une règle fondamentale :

Les opérateurs surchargés doivent conserver leur rôle naturel sous peine de perturber considérablement leur utilisateur

En effet, le but des opérateurs surchargés est de faciliter l'écriture de code. Autrement dit, l'utilisateur de vos opérateurs ne doit pas avoir à se poser de question lorsqu'il va les utiliser, et ce n'est pas en modifiant le comportement des plus élémentaires que vous atteindrez ce but.

Par exemple, l'opérateur d'évaluation séquentielle est très bien comme il est. Et, à moins de vouloir régler son compte à un ennemi, vous n'avez aucun intérêt à le surcharger. La même règle s'applique directement au non logique.

Pour ce qui concerne les opérateurs logiques dyadiques, il existe une autre règle encore plus subtile. En effet, en C++ comme en C, les évaluations sont dites à court circuit. En effet, si le premier membre d'un « et » est faux, il est inutile d'évaluer le reste de l'expression, le résultat sera faux quoiqu'il arrive. Réciproquement, l'évaluation d'une expression « ou » s'arrête dès que l'on rencontre un membre vrai. Considérez maintenant la redéfinition des opérateurs || et &&. Leurs cas étant symétriques, nous n'allons étudier que le « ou ». Il s'écrira ainsi :

bool operator||(const bool a, const bool b)

(Notez au passage l'utilisation des valeurs directes des booléens et non pas de références : sizeof(bool) < sizeof(@) !)

… et souvenez-vous ! les arguments d'une fonction sont toujours évalués in extenso avant l'appel de la fonction ! ainsi, il ne peut plus y avoir de court circuit et une expression telle que, par exemple :

if (p && *p>0)

qui pouvait être écrite sans danger en C++ ne peut plus l'être du fait de votre surcharge (la déréférence du pointeur sera faite même si ce dernier est nul, première clause du &&).

Typiquement, les opérateurs doivent toujours prendre les paramètres susceptibles d'être modifiés par référence.

Les paramètres qui ne doivent pas être modifiés sont soit :

• passés par référence constante ;
• passés par valeur s'il s'agit de scalaires dont la taille est inférieure à celle d'un pointeur, en aucun cas, on ne passera un objet par valeur.

II-D-1. Préférer les références constantes aux objets▲

class Evaluable
{
    protected:
        int (*f)(void);
        // détails omis
    public:
        // Evaluation simple : utilisation de la fonction objectif
    virtual int evaluation(void) const
    {
        return (*f)();
    }
};

bool operator<(Evaluable gauche, Evaluable droite)
    {
        return (gauche.evaluation() < droite.evaluation());
    }

class Penalites : public Evaluable
{
    private:
        int facteurPenalites;
        int violation;
    public:
        // Evaluation avec penalites quadratiques !
        virtual int evaluation(void) const
        {
            return (*f)() + facteurPenalites*violation*violation;
        };
};

int main(int, char**)
{
    Evaluable e1,e2;
    Penalites p1,p2;
 
    if (e1 < e2) // utilise Evaluable::evaluation
        // code omis
 
    if (p1 < p2) // utilise egalement Evaluable::evaluation !!!!
        // code omis
}

bool operator<(const Evaluable &gauche, const Evaluable &droite)
{
    return (gauche.evaluation() < droite.evaluation());
}

II-D-2. Pourquoi ne pas toujours renvoyer une référence▲

Il faut séparer deux grands cas dans les types de retour :

Les types de retour scalaires ne posent aucun problème particulier : le résultat est logé sur la pile ou dans un registre du processeur avant d'être récupéré par l'appelant.

Les types de retour objet sont plus complexes à gérer, car l'on se retrouve souvent face à un dilemme : doit-on retourner un objet ou une référence ?

À la question :

Quand peut-on (et doit-on !) absolument renvoyer une référence ?

Nous pourrons répondre :

« Il est nécessaire de renvoyer une référence lorsque l'opérateur (ou une méthode quelconque) doit renvoyer l'objet cible (i.e. *this) de manière à ce que celui-ci soit modifiable. C'est typiquement le cas des opérateurs dont le résultat lvalue, c'est-à-dire une expression que l'on peut positionner à gauche d'un signe d'affectation. Dans cette catégorie, on retrouve notamment tous les opérateurs d'affectation et assimilés ainsi que l'opérateur de préincrémentation. »

Dans tous les autres cas, il vaudra mieux retourner un objet. Afin d'étayer notre propos, considérons une classe modélisant les nombres rationnels et déclarée comme suit :

class Rationnel
{
    private:
        int numerateur;
        int denominateur;
    public:
        Rationnel (int numVal, int denVal) :
        numerateur(numVal), denominateur(denVal)
    {
    }
    // déclarations omises
    int num() const
    {
        return numerateur;
    }
    int deno() const
    {
        return denominateur;
    }
};

Écrivons dorénavant un opérateur de multiplication sur les rationnels, la première idée de codage est la suivante :

Rationnel operator*(const Rationnel &gauche, const Rationnel &droite)
{
    return Rationnel(gauche.num()*droite.num(),
                     gauche.deno()*droite.deno());
}

Écrit tel quel, cet opérateur renvoie un objet Rationnel. Examinons maintenant la ligne de code suivante (qui suppose l'existence préalable de deux objets Rationnel a et b) :

Rationnel c(0,0);
// code omis
c=a*b;

Typiquement, voici le comportement de cette instruction telle que spécifié dans la documentation officielle du C++.

1. Appel de la fonction operator* avec passage par référence constantes des objets a et b.
2. Construction de l'objet temporaire résultat sur la pile dans l'espace automatique de operator* par le constructeur Rationnel(int,int).
3. Instruction return. L'objet temporaire créé précédemment (par le constructeur Rationnel(int,int)) est recopié dans un espace temporaire, sur la pile, mais en dehors de l'espace automatique de operator* afin que ce nouvel objet ne soit pas détruit lors du retour de la fonction. Nous appellerons cet objet retour_temp.
   Notez que dans ce cas, où la classe rationnelle n'a que des attributs scalaires, le constructeur par recopie automatiquement fourni par le compilateur (vous savez, celui qui fonctionne par recopie bit à bit « optimisée ») est parfait.
4. Sortie de la fonction operator*. L'objet temporaire Rationnel(int,int) construit par est détruit au contraire de l'objet retour_temp placé en dehors de la zone automatique de operator*.
5. L'opérateur d'affectation sur la classe Rationnel (une fois encore, l'opérateur automatiquement créé par le compilateur est suffisant) est appelé sur l'objet c avec pour paramètre retour_temp.
6. L'objet retour_temp devenu inutile est détruit.

Ce comportement peut paraître lourd, mais il s'avère particulièrement sûr. En effet, il évite, par exemple, que l'objet temporaire créé par le constructeur

Rationnel(int,int) ne soit détruit avant son utilisation à l'extérieur de la fonction.

En outre, certains compilateurs sont capables de réaliser de « l'optimisation de return ». Plutôt que d'utiliser un constructeur par recopie pour fabriquer l'objet retour_temp, en dehors de la zone de pile détruite au moment du retour, le compilateur créé directement l'objet Rationnel(int,int) dans cet emplacement privilégié s'épargnant ainsi un appel au constructeur de recopie.

Toutefois, le programmeur soucieux de performance est en mesure de se poser la question :

Si les références sont si efficaces pour passer les paramètres, pourquoi n'utiliserais-je pas une référence comme type de retour ?

L'opérateur de multiplication pourrait alors s'écrire :

Rationnel &operator*(const Rationnel &gauche, const Rationnel &droite)
{
return Rationnel(gauche.num()*droite.num(),
gauche.deno()*droite.deno());
}

Vous remarquez que l'on renvoie une référence sur un objet automatique, ce qui n'est pas sans rappeler une erreur fréquente des programmeurs en C qui renvoient l'adresse d'une variable automatique : les conséquences sont exactement les mêmes : l'affectation suivante va se faire sur un objet qui n'existe plus.

Qu'à cela ne tienne me direz-vous, je n'ai qu'à construire mon objet sur le tas, on obtient alors :

Rationnel &operator*(const Rationnel &gauche, const Rationnel &droite)
{
return *(new Rationnel(gauche.num()*droite.num(),
gauche.deno()*droite.deno()));
}

Le problème précédent est en effet éliminé : la référence renvoyée n'est plus sur un objet temporaire. Toutefois, qui va se charger d'appeler delete sur l'objet créé dans l'opérateur pour rendre la mémoire ?

Dans le cas où l'on réalise une opération simple, ce n'est pas trop grave, on pourra toujours avoir :

c=a*b;
delete &c;

C'est très contraignant (et source rapide d'erreurs -), mais ça marche ! En revanche considérez l'expression :

d=a*b*c;

Celle-ci se réécrit en fait :

d=operator*(a,operator*(b*c));

Alors, quelle solution choisir ? il vaut mieux jouer la sécurité et adopter la première solution : celle qui renvoie des objets. Il est vrai que l'on risque d'utiliser un opérateur de recopie supplémentaire, mais il vaut mieux perdre un peu de temps que risquer de dilapider la mémoire ou travailler sur des objets en cours de destruction, ne croyez vous pas ?

Nous discutons ici des opérateurs d'incrémentation au sens large, tout ce discours s'appliquant également aux opérateurs de décrémentation. Les opérateurs d'incrémentation sont particuliers à bien des aspects. En particulier ils peuvent être utilisés en préincrémentation (++i) ou en postincrémentation (i++). La première difficulté va donc être de séparer ces deux formes. Le C++ emploie pour cela une astuce assez sale. En effet, l'opérateur de préincrémentation est déclaré sans paramètre, alors que l'opérateur de postincrémentation prend un paramètre int muet. En outre, reste le problème de leur type de retour.

Une fois de plus, nous nous basons sur le comportement de ces opérateurs sur le type canonique int.

Par exemple, l'expression

++i=5;

est tout à fait valide, au contraire de :

i++=5;

En effet, dans le second cas, il y a conflit dans l'ordre des opérations entre l'affectation et la postincrémentation. Pour résumer, il nous suffit de dire que ++X est une lvalue, au contraire de X++. Ce qui nous indique clairement que l'opérateur de préincrémentation doit renvoyer une référence sur *this alors que l'opérateur de postincrémentation doit renvoyer un objet constant.

Finalement, nous obtenons les déclarations suivantes pour une classe X quelconque :

class X
{
// code omis
public:
X & operator++(void); // préincrémentation
const X operator++(int); // postincrémentation
};

D'autre part, reprenons un manuel (un bon, de préférence) de génie logiciel. Vous y trouverez probablement, sous quelque forme que ce soit, l'adage suivant :

Toute duplication de code est à proscrire

Nous allons l'appliquer à la rédaction de nos opérateurs d'incrémentation. En effet, il est évident de remarquer que l'opérateur de postincrémentation peut toujours s'écrire de la manière suivante une fois l'opérateur de préincrémentation écrit :

const X X::operator++(int)
{
const X temp=const_cast<const X>(*this); // copie de l'objet dans
// son état actuel
operator++(); // pre incrementation
return temp;
}

En effet, il suffit d'écrire une fois le code d'incrémentation et ce dans l'opérateur de préincrémentation, lequel renvoie toujours *this. Le code de l'opérateur de postincrémentation est alors trivial. On assiste alors au gigantesque gâchis réalisé par l'opérateur de postincrémentation :

1. Construction d'un objet temporaire par le constructeur de recopie, lequel sera renvoyé par la méthode ;
2. Appel à l'opérateur de préincrémentation pour réaliser effectivement l'incrémentation ;
3. Renvoi de l'objet créé précédemment, avec, si le compilateur ne fait pas d'optimisation de retour, appel au constructeur de recopie.

On voit bien que la postincrémentation est une opération beaucoup plus onéreuse que la préincrémentation. Aussi, dès lors que l'on pourra faire soit l'une, soit l'autre, il faudra toujours utiliser la préincrémentation.

Les opérateurs new et delete sont particulièrement spéciaux, car ils gèrent l'allocation et la désallocation des objets. Avant de se poser la question de leur surcharge, nous allons d'abord nous intéresser à leur fonctionnement détaillé.

II-G-1. Bien comprendre le fonctionnement de new et delete▲

X *x=new X(-)

II-G-2. Une version spéciale de new : operator new de placement▲

X *X::operator new(void *a)
{
return a;
}

II-G-3. Exercice : un exemple simpliste de surcharge de new et▲

Le schéma général s'appuie sur la description de blocs protégés suivis de code de prise en charge des exceptions appelé traite exception ou gestionnaire d'exception.

Il est important de faire d'ores et déjà quelques commentaires importants.

• Un gestionnaire utilise toujours une référence sur un type d'exception. Lorsque l'exception correspondante est levée, il se sert de l'identificateur pour accéder aux données membres ou aux méthodes de l'exception.
• Il existe un gestionnaire universel qui est introduit par la séquence catch (-). Il convient toutefois de ne l'utiliser que dans des circonstances limitées c'est-à-dire lorsque vous maîtrisez l'ensemble des exceptions qui risquent d'être levées par le bloc de code incriminé. En effet, ce gestionnaire intercepte n'importe quelle exception.
  Hors certains environnements de programmation encapsulent toute la fonction main à l'intérieur d'un bloc try et fournissent des gestionnaires spécifiques à certaines exceptions. Si vous utilisez catch (…) à l'intérieur d'un tel bloc, vous risquez de court-circuiter les mécanismes de gestion de telles interruptions avec des conséquences parfois dramatiques.
  Aussi, il vaut mieux, comme nous le verrons plus loin, utiliser des hiérarchies bien pensées de vos exceptions.

Lorsqu'une exception est levée dans votre programme, que se passe-t-il ?

• Si l'instruction en faute n'est incluse dans un bloc try, il y appel immédiat de la fonction terminate.

Comme son nom l'indique, cette dernière provoque la terminaison immédiate du programme par l'appel à la fonction abort (l'équivalent d'un SIG_KILL sous Unix) sans aucun appel de destructeur ou de code de nettoyage ; ce qui s'avère la plupart du temps désastreux.

Notons également que terminate est appelée par défaut par la fonction unexpected.

Pour terminer par une note optimiste, il est possible de modifier le fonctionnement de terminate en utilisant la fonction set_terminate.

• En revanche, si l'instruction incriminée est incluse dans un bloc try, le programme saute directement vers les gestionnaires d'exception qu'il examine séquentiellement dans l'ordre du code source.

  • Si l'un des gestionnaires correspond au type de l'exception, il est exécuté, et, s'il ne provoque pas lui même d'interruption ou ne met fin à l'exécution du programme, l'exécution se poursuit à la première ligne de code suivant l'ensemble des gestionnaires d'interruption. En aucun cas il n'est possible de poursuivre l'exécution à la suite de la ligne de code fautive.
  • Si aucun gestionnaire ne correspond au type de l'exception, celle-ci est propagée au niveau supérieur de traitement des exceptions (ce qui signifie le bloc try de niveau supérieur en cas de blocs try imbriqués) jusqu'à arriver au programme principal qui lui appellera terminate.

Dans certains cas, il est impossible de traiter localement une exception. Toutefois, le cas n'est pas jugé suffisamment grave pour justifier l'arrêt du programme. Le comportement standard consiste alors à relever l'exception incriminée (après, par exemple, un avertissement à l'utilisateur) dans l'espoir qu'un bloc de niveau supérieur saura la traiter convenablement. Ceci se fait en utilisant l'instruction throw isolée comme le montre l'exemple suivant :

try
{
}
catch (TypeException &e)
{
    // code de traitement local
    throw; // Relance l'exception
}

III-D-1. Déclarer ses exceptions▲

Selon la norme, les exceptions peuvent être de n'importe quel type (y compris un simple entier). Toutefois, il est pratique de les définir en tant que classes. Afin de ne pas polluer l'espace global de nommage, il est possible d'encapsuler les exceptions à l'intérieur des classes qui les utilisent.

En outre, et sans vouloir empiéter sur le cours concernant la librairie standard du C++ (STL), il me semble adéquat de dériver toute exception du type std::exception proposé en standard par tous les compilateurs modernes -.

En effet, cette classe propose une méthode nommée what qui peut s'avérer des plus précieuses. Examinons le code suivant :

Programme 3.2 Déclaration de la classe std::exception

Sélectionnez

class exception
{
 
    // code omis
    virtual const char * what () const throw ()
    {
        return << pointeur vers une chaine quelconque >> ;
    }
};

De toute évidence, la méthode what est destinée à être surchargée par chaque classe dérivée de std::exception afin de fournir à l'utilisateur un message le renseignant sur la nature de l'erreur levée.

En outre, cela permet de récupérer votre exception avec une clause :

 

Sélectionnez

catch (std::exception &e)

plutôt qu'en utilisant l'infâme :

 

Sélectionnez

catch(-)

Considérons par exemple une classe nommée TasMax et implémentant les fonctionnalités d'un Tas max (on s'en doutait un peu -). Les erreurs peuvent être multiples :

• erreurs d'allocation ;

• erreurs d'accès aux éléments, lesquelles seront principalement :

  • tentative de dépilage d'un élément sur un tas vide,
  • tentative d'empilage d'un élément sur un tas déjà plein.

Afin de se simplifier l'existence, il est agréable d'utiliser une classe mère de toutes les classes d'exception que l'on peut lancer. La hiérarchie devient alors :

Le code associé peut être :

Programme 3.3 Exemple d'une hiérarchie d'exceptions

Sélectionnez

class TasMax
{
public:
 
    class Erreur : public std::exception
    {
        const char *what(void) const throw()
        {
            return "Exception generale sur un tas max";
        }
    };
 
    class ErreurAcces : public TasMax::Erreur
    {
    const char *what(void) const throw()
        {
            return "Exception d'acces sur un tas max";
        }
    };
 
    class ErreurTasVide : public TasMax::ErreurAcces
    {
        const char *what(void) const throw()
            {
                return "Exception de depilement d'un tas max vide";
            }
    };
 
    class ErreurTasPlein : public TasMax::ErreurAcces                
    {
        const char *what(void) const throw()
            {
                return "Exception d'empilement sur un tas max plein";
            }
    };
 
    class ErreurAllocation : public TasMax::Erreur
    {
        const char *what(void) const throw()
        {
            return "Impossible d'allouer de la memoire dans le tas max";
        }
    };
 
    // reste du code omis
};

Vous remarquerez au passage que ce code utilise des noms complètement qualifiés pour dériver les classes imbriquées. Ceci n'est pas requis par la norme du C++, mais permet parfois de lever certaines ambiguïtés, en particulier lorsque les identificateurs sont très simples.

III-D-2. Utiliser ses exceptions▲

catch (TypeException &e)

try
{
    // bloc de code protégé
}
catch (TasMax::ErreurTasVide &e)
{
    // code spécifique à cette exception
}
catch (TasMax::Erreur &e)
{
    cerr << &#8220;Le Tas Max a provoqué l'exception : &#8220; << e.what() << endl;
    cerr << &#8220;Fin du programme&#8221; << endl;
    exit(1);
}
catch (std::exception &e)
{
    cerr << &#8220;Exception inconnue : &#8220; << e.what() << endl;
    cerr << &#8220;Fin du programme&#8221; << endl;
    exit(1);
}

Lecteur attentif, vous n'aurez pas manqué de vous interroger sur la signification de la clause throw() à la fin du prototype de la méthode what de la classe std::exception (voir Programme 3.2).

C'est ce que l'on appelle un spécificateur d'exception et renseigne l'utilisateur sur le type des exceptions que peut renvoyer une méthode. Ceci paraît très attractif, on sait immédiatement à quel type d'exceptions l'on doit s'attendre au moment de les intercepter, et, le compilateur vous empêche de lancer une exception non prévue par votre spécificateur. Par exemple, le code suivant est interdit :

void TasMax::depiler(void) throw (TasMax::ErreurTasVide)
{
    -
    throw TasMax::Erreur(); // exception non prévue dans la spécification
}

Mais, car il y a un mais, le spécificateur d'exception interdit aux autres méthodes ou fonctions appelées d'invoquer des exceptions non prévues. Or, ce point est difficile à vérifier lors de la compilation. Plus grave, à l'exécution, si une exception non prévue par le spécificateur est lancée, la norme prévoit que la fonction unexpected soit invoquée, laquelle, appelle immédiatement terminate avec les conséquences que nous avons déjà vues précédemment. Il est toutefois possible de modifier ce comportement en modifiant unexpected grâce à la fonction set_unexpected.

Aussi, les spécificateurs d'exception doivent-ils être réservés au code que vous maîtrisez totalement et plus spécifiquement aux méthodes pour lesquelles vous êtes en mesure de prévoir le déroulement complet. Par exemple, dans le cas du Tas Max, vous pourriez écrire :

TasMax(int taille=10) throw (TasMax::ErreurAllocation);
void empiler(int valeur) throw (TasMax::ErreurTasPlein);
int meilleurElement(void) throw (TasMax::ErreurTasVide);
void depiler(void) throw (TasMax::ErreurTasVide);

Mettez vite Procol Harum sur la platine 33 tours de vos parents, coiffez vous d'une perruque hippie, faîtes passez un Censuré dans l'assistance et souvenez vous de l'opérateur de conversion (cast) du langage C que nous aimons tous tellement. Sa syntaxe est la suivante :

(nouveau type)(expression à transtyper)

où les parenthèses autour de l'expression à transtyper peuvent être omises si celle-ci est très simple et si vous être pris de pulsions suicidaires. La nouvelle syntaxe est la suivante :

type(expression à transtyper)

C'est beaucoup plus simple et en outre, à l'avantage de vous obliger à utiliser typedef pour les types pointeur.

En effet, considérez le transtypage :

Y *y;
X *x=(X *)y

Pour l'écrire avec la nouvelle syntaxe, il vous vaut passer par un typedef :

typedef X* PX;
Y *y;
X *x=PX(y)

Bien que simplificatrice, la nouvelle syntaxe n'était pas satisfaisante à bien des points de vue, car elle ne fait que simplifier l'écriture des transtypages et ne corrige aucun des défauts de l'opérateur traditionnel (par ordre croissant de sévérité) :

• elle est dure à retrouver dans un code source, car ce n'est ni plus ni moins qu'un nom de type et une paire de parenthèses ;
• elle permet de mixer dangereusement les objets constants et non constants ;
• elle permet de réaliser n'importe quel type de promotion, ou transtypage de pointeur descendant ou encore downcast.

Rappelons rapidement ce qu'est un downcast. Il s'agit d'une conversion d'un pointeur sur un objet d'une classe générale vers un objet d'une classe spécialisée. Si l'opération est légitime, cela ne posera pas de problème spécifique. En revanche, si l'opération est illégitime, vous essayerez probablement d'accéder à des informations inexistantes avec tous les problèmes de mémoire conséquents.

Les nouveaux opérateurs vont permettre de résoudre ces problèmes.

IV-B-1. Pourquoi ?▲

IV-B-2. Syntaxe▲

op_cast<expression type>(expression à transtyper)

int i;
double d;
i=static_cast<int>(d)

IV-B-3. Fonctionnalités▲

IV-B-3-a. L'opérateur static_cast▲

C'est l'opérateur de transtypage à tout faire qui remplace dans la plupart des cas l'opérateur hérité du C. Toutefois il est limité dans les cas suivants :

• il ne peut convertir un type constant en type non constant ;
• il ne peut pas effectuer de promotion (downcast).

IV-B-3-b. L'opérateur const_cast▲

Il est spécialisé dans l'ajout ou le retrait des modificateurs const et volatile.

En revanche, il ne peut pas changer le type de données de l'expression. Ainsi, les seules modifications qu'il peut faire sont les suivantes :

X	->	const X
const X	->	X
X	->	volatile X
volatile X	->	X
const X	->	volatile X
volatile X	->	const X

Tableau 4.1 Transtypages réalisables avec const_cast

Le code suivant illustre l'intérêt de const_cast, le résultat de la compilation (avec gcc) est placé en commentaire.

Programme 4.2 exemple d'utilisation de const_cast

Sélectionnez

        X t1(-);
const   X t2(-);
        X *t11=&t1;
const    X *t22=&t2;
 
    t11=&t2; // warning: assignment to `X *' from `const X *' discards const
    t11=static_cast<X *>(&t2); // error: static_cast from `const X *' to `X *'
    t11=const_cast<X *>(&t2); // Ok !

IV-B-3-c. L'opérateur dynamic_cast▲

Les downcast posent un problème particulier, car leur vérification n'est possible qu'à l'exécution. Aussi, contrairement à static_cast et const_cast qui ne sont que des informations à l'adresse du compilateur, dynamic_cast génère du code de vérification.

Supposons que vous disposez d'un conteneur agrégeant par pointeur différents objets issus d'une lignée d'objets graphiques représentée par la figure suivante :

Si le conteneur est basé sur le type ObjetGraphique *, nous n'avons pas la possibilité de connaître le type exact d'un objet issu du conteneur à un instant quelconque.

Sortons un objet du conteneur. Décidons qu'il s'agit d'un Cercle et essayons de lui appliquer la méthode setRayon typique de la classe Cercle. Cette opération nécessite la promotion du pointeur depuis ObjetGraphique* vers Cercle*. Nous allons nous assurer de la légitimité de l'opération grâce à dynamic_cast par le code suivant :

Programme 4.3 utilisation typique de dynamic_cas

Sélectionnez

ObjetGraphique *g= - / recupération d'un pointeur dans un conteneur
Cercle *c=dynamic_cast<Cercle *>(g)t

À l'exécution, le programme va s'assurer que l'opération est légitime en utilisant des informations de types codées dans les objets et connues sous le nom de RTTI (Run Time Type Information). Cette fonctionnalité sera étudiée dans les chapitres consacrés à la Librairie Standard du C++.

IV-B-3-d. Exercices sur les nouveaux opérateurs de conversion▲

Énoncé : Commenter les opérations de transtypage suivantes :

 

Sélectionnez

ObjetGraphique *o;
const Ligne     ligne;
Cercle             cercle;
const Cercle     *pCercle;
Ligne             *pLigne;
 
1) pCercle = const_cast<const Cercle *>(&cercle);
2) pLigne = dynamic_cast<Ligne *>(pCercle);
3) o = static_cast <ObjetGraphique *>(&ligne);

Solution :

1. Pas de problème : &cercle de type Cercle* devient un pointeur constant par l'utilisation de const_cast

2. Erreur : il n'est pas possible d'ajouter ou de supprimer le caractère const avec dynamic_cast. Deux solutions sont possibles :

   1. convertir pCercle en pointeur non constant puis traverser la hiérarchie avec dynamic_cast, soit : pLigne=dynamic_cast ;
   2. faire le const_cast à la fin, c'est-à-dire :

3. Même problème que précédemment : static_cast ne permet pas d'ajouter ou de retirer le caractère constant d'un pointeur. En outre, afin de s'assurer que la conversion est légitime, il eut mieux valu utiliser dynamic_cast. On retrouve alors les deux solutions :

   1. o=const_cast ;
   2. o=dynamic_cast.

Une conversion implicite est un transtypage effectué par le compilateur dans votre dos, l'exemple le plus simple concerne les conversions implicites entre types numériques.

Il y a toutefois deux cas nettement plus graves où le C++ est en mesure d'effectuer des conversions implicites : les opérateurs de conversion et les constructeurs à un seul paramètre.

IV-C-1. Les opérateurs de conversion implicites▲

operator type_desire(void)

class Rationnel
{
    // -
    operator double (void)
    {
        return double(numerateur)/denominateur;
    }
};

{
double a=0.0;
double c;
Rationnel r(1,2);
c = a + r;
}

Rationnel r1(1,2);
Rationnel r2(1,3);
 
// Tentative de comparaison des numérateurs
// Le code devrait être (r1.num() == r2.num())
 
if (r1.num() == r2) // faute de frappe
{
    .. reste du code omis -
}

IV-C-2. Les constructeurs avec un seul paramètre▲

class Chaine
{
    public:
        Chaine (int param) - // Crée une chaine de param caractères non
                             // initialisés
};

Chaine c1= new Chaine(”tklp”);
Chaine c2= new Chaine(”tkop”);
 
for (int i=0;i<c1.size();i++)
{
    if (c1==c2[i]) // Erreur de frappe ! ce devrait être c1[i]
    -
}