swap( v_, other.v_ );
swap( vsize_, other.vsize_ );
swap( vused_, other.vused_ );
}
Figure 1. Deux objets StackImpl<T>a et b
,,,,,,,,,
Pour mieux visualiser le fonctionnement de Swap(), prenons l’exemple de deux objets StackImpl<T>a et b, représentés sur la figure 1.
Voici ce que deviennent ces deux objets après exécution de l’instruction
a.Swap(b):
Figure 2. Les mêmes objets StackImpl<T>, après a.Swap(b)
On peut noter au passage que la fonction Swap() ne génèrera jamais d’exception, par construction. C’est d’ailleurs pour cela qu’elle sera la pierre angulaire de la robus-tesse aux exceptions de notre nouvelle version de Stack.
La raison d’être de StackImpl est simple : son rôle est de masquer à la classe externe Stack les détails d’implémentation liés à la gestion des zones de mémoire dynamique. D’une manière générale, il est toujours préférable de recourir le plus pos-sible à l’encapsulation et de séparer les responsabilités.
Passons maintenant à la troisième question : par quoi peut-on remplacer le com-mentaire /*????*/ inclus dans la déclaration de StackImpl ? La véritable question sous-jacente est plutôt : comment StackImpl sera-t-elle utilisée par Stack ? Il y a en C++ deux possibilités techniques pour mettre en oeuvre une relation « EST-IMPLE-MENTE-EN-FONCTION-DE »: l’utilisation d’une classe de base privée ou l’utilisa-tion d’une variable membre privée.
Technique n° 1 : classe de base privée. Dans ce cas de figure, le commentaire doit être remplacé par protected1 (les fonctions privées ne pouvant pas être appelées depuis la classe dérivée). La classe Stack dériverait de la classe StackImpl de manière privée et lui déléguerait toute la gestion de la mémoire, assurant pour sa part, Recommandation
Efforcez-vous de toujours découper votre code de manière à ce que chaque unité d’exécu-tion (chaque module, chaque classe, chaque foncd’exécu-tion) ait une responsabilité unique et bien définie.
1. L’emploi de public serait également techniquement possible, mais pas conforme à l’uti-lisation que l’on souhaite faire de StackImpl ici.
,,,,,,,,,
,,,,,,,
yyyyyyyyy
yyyyyyy
YB YVL]HB YXVHGB
a
,,,,,
,,,,
yyyyy
YB yyyy
YVL]HB YXVHGB
b
outre les diverses fonctionnalités du conteneur, la construction des objets T contenus.
Le fait de séparer clairement l’allocation/désallocation du tableau de la construction/
destruction des objets contenus présente de nombreux avantages : en particulier, nous sommes certains que l’objet Stack ne sera pas construit si l’allocation – effectuée dans le constructeur de StackImpl – échoue.
Technique n° 2 : membre privé. Dans cette deuxième solution, le commentaire doit être remplacé par public. Le conteneur Stack serait toujours « IMPLEMENTE-EN-FONCTION-DE » de la classe StackImpl, mais en lui étant cette fois lié par une rela-tion de type « A-UN ». Nous avons, ici encore, une sépararela-tion nette des responsabilités : la classe StackImpl gérant les ressources mémoires tandis que la classe Stack gère la construction/destruction des objets contenus. Du fait que le constructeur d’une classe est appelé après les constructeurs des objets membres, nous sommes également assurés que l’objet Stack ne sera pas construit si l’allocation de la zone mémoire échoue.
Ces deux techniques sont très similaires mais présentent néanmoins quelques dif-férences. Nous allons étudier successivement l’une puis l’autre, dans les deux problè-mes suivants.
Le but de ce problème est d’implémenter une deuxième version du modèle de classe Stack, dérivant de la classe StackImpl étudiée dans le problème précédent (dans laquelle on remplacera donc le commentaire par protected) :
template <class T>
class Stack : private StackImpl<T>
{ public:
Stack(size_t size=0);
~Stack();
Stack(const Stack&);
Stack& operator=(const Stack&);
size_t Count() const;
void Push(const T&);
T& Top(); // Lance une exception si la pile est vide void Pop(); // Lance une exception si la pile est vide };
Proposez une implémentation pour chacune des fonctions membres de Stack, en faisant bien entendu appel aux fonctions adéquates de la classe de base StackImpl.
P
B N° 13. É
CRIRE DU CODE ROBUSTE AUX EXCEPTIONS(6
e PARTIE) D
IFFICULTÉ: 9
Nous étudions dans ce problème une nouvelle version de Stack, utilisant StackImpl comme classe de base, qui nous permettra de diminuer le nombre de contraintes imposées au type contenu et d’obtenir une implémentation très élégante de l’opérateur d’affectation.
Bien entendu, la classe Stack doit toujours être parfaitement robuste aux exceptions.
Signalons, au passage, qu’il existe une manière très élégante d’implémenter la fonc-tion operator=().
Constructeur par défaut
Voici une proposition d’implémentation pour le constructeur par défaut de
Stack (on présente une implémentation en-ligne à des fins de concision) :
template <class T>
class Stack : private StackImpl<T>
{ public:
Stack(size_t size=0) : StackImpl<T>(size) {
}
Ce constructeur fait simplement appel au constructeur de la classe de base Stac-kImpl, lequel initialise l’état de l’objet et effectue l’allocation initiale de la zone mémoire. La seule fonction susceptible de générer une exception est le constructeur de StackImpl. Il n’y a donc pas de risque de se retrouver dans un état incohérent : si une exception se produit, l’objet Stack ne sera jamais construit (voir le problème n° 8 pour plus de détails au sujet des constructeurs lançant des exceptions).
On peut noter au passage une légère modification de la déclaration du constructeur par défaut par rapport aux problèmes précédents : nous introduisons ici un paramètre
size, avec une valeur par défaut de 0, permettant de spécifier la taille initiale du tableau et que nous aurons l’occasion d’utiliser lors de l’implémentation de la fonc-tion Push.
Destructeur
Nous n’avons pas besoin d’implémenter de destructeur spécifique pour la classe
Stack, ce qui est assez élégant. En effet, le destructeur de StackImpl, appelé par l’implémentation par défaut du destructeur de Stack, détruit correctement tous les objets contenus et effectue la désallocation du tableau interne.
S
OLUTIONRecommandation
Pour une meilleure robustesse aux exceptions, encapsulez le code gérant les ressources externes (zones de mémoire dynamique, connexions à des bases de données,...) en le séparant du code utilisant ces ressources.
Constructeur de copie
Voici une proposition d’implémentation, utilisant la fonction construct()
détaillée lors du problème précédent :
Stack(const Stack& other) : StackImpl<T>(other.vused_) {
while( vused_ < other.vused_ ) {
construct( v_+vused_, other.v_[vused_] );
++vused_;
} }
Nous avons ici une implémentation efficace et élégante du constructeur de copie de Stack (dont on peut remarquer, au passage, qu’elle ne fait pas appel au constructeur de copie de StackImpl). Si le constructeur de T – appelé depuis la fonc-tion construct()– lance une exception (c’est la seule source possible ici), le destruc-teur de StackImpl est appelé, ce qui a pour effet de détruire tous les objets T déjà construits et de désallouer correctement le tableau mémoire interne. Nous voyons ici l’un des grands avantages de l’utilisation de StackImpl comme classe de base : nous pouvons implémenter autant de constructeurs de Stack que nous le désirons, sans avoir à nous soucier explicitement des destructions et désallocations en cas d’échec de la construction.
Opérateur d’affectation
Nous présentons ici une version très élégante et très robuste de l’opérateur d’affec-tation de Stack :
Stack& operator=(const Stack& other) {
Stack temp(other); // Fait tout le travail
Swap( temp ); // Ne peut pas lancer d’exception return *this;
}
Élégant, n’est-ce pas ? Nous avons déjà vu ce type de technique lors du problème n° 10, rappelons-en le principe fondateur :
Recommandation
Lorsque vous implémentez une fonction destinée à réaliser une certaine opération, sépa-rez les instructions effectuant l’opération elle-même (susceptibles de générer une exception), du code réalisant la validation de cette opération, constitué d’instructions unitaires (ne risquant pas de générer des exceptions).
Nous construisons un objet Stack temporaire (temp), initialisé à partir de l’objet source (other) puis nous appelons Swap (membre de la classe de base) pour échanger l’état de notre objet temporaire avec celui de l’objet passé en paramètre; lorsque la fonction se termine, le destructeur de temp est automatiquement appelé, ce qui a pour effectuer de désallouer correctement toutes les ressources liées à l’ancien état de notre objet Stack.
Notons qu’implémenté de cette manière, l’opérateur d’affectation gère correcte-ment, de manière native, le cas de l’auto-affectation ( « Stack s; s=s; »). Voir le problème n° 38 pour plus d’informations sur l’auto-affectation, et notamment sur l’emploi du test « if (this != &other) » dans un opérateur d’affectation).
Les sources d’exceptions potentielles sont l’allocation ou la construction des objets T. Comme elles ne peuvent se produire que lors de la construction de l’objet
temp, nous sommes assurés qu’en cas d’échec, l’impact sur notre objet Stack sera nul. Il n’y a pas non plus de risque de fuite mémoire liée à l’objet temp, car le constructeur de copie de Stack est parfaitement robuste de ce point de vue. Une fois que nous sommes certains que l’opération a été effectuée correctement, nous la vali-dons en mettant à jour l’état de notre objet Stack grâce à la fonction Swap() , laquelle ne peut pas lancer d’exceptions (elle est déclarée avec une spécification d’exceptions
throw et n’effectue, de toute façon, que des copies de valeurs de types prédéfinis).
Cette implémentation est largement plus élégante que celle proposée lors du pro-blème n° 9; elle est également plus simple, ce qui permet de s’assurer d’autant plus facilement de son bon comportement en présence d’exceptions.
Il est d’ailleurs possible de faire encore plus compact, en utilisant un passage par valeur au lieu d’une variable temporaire :
Stack& operator=(Stack temp) {
Swap( temp );
return *this;
}