XXIV. À retenir▲
Par défaut, en C++, les fonctions membres ne sont pas virtuelles. Le mot-clé virtual est nécessaire pour définir une fonction virtuelle.
L'appel d'une fonction virtuelle sur un pointeur ou une référence utilise le type dynamique et est résolu à l'exécution.
Le type statique d'un pointeur ou d'une référence est celui défini dans le code. Le type dynamique est celui de l'objet effectivement pointé/référencé.
Un destructeur d'une classe utilisée pour l'héritage public doit être virtuel s'il est public ou protégé s'il est non virtuel.
Un destructeur public et non virtuel indique que la classe ne doit pas être utilisée pour un héritage public.
Une fonction virtuelle ne peut être inlinée dans un appel polymorphe.
Appeler une fonction virtuelle dans un constructeur ou un destructeur n'appelle pas la fonction la plus spécialisée de l'objet en cours de construction, mais celle disponible pour le constructeur en cours d'exécution.
L'appel d'une fonction virtuelle pure dans le constructeur ou le destructeur d'une classe abstraite produit un comportement indéterminé.
Evitez d'introduire des masquages de fonctions.
Une fonction générique (template) ne peut pas être virtuelle.
Une classe générique peut avoir des fonctions membres virtuelles.
L'amitié ne s'hérite pas : déclarer amie une fonction virtuelle est faiblement utile.
Une fonction virtuelle ne peut s'engager à lever plus d'exceptions que celles précisées dans la définition la plus spécialisée de ses classes de base.
Les préconditions d'une fonction virtuelle dans la classe dérivée ne peuvent être plus restrictives que celle de la définition la plus spécialisée de ses classes de base. En revanche, elles peuvent être plus lâches autorisant l'utilisation de la spécialisation avec le type dérivé là où la classe de base ne sait pas faire.
Les postconditions d'une fonction virtuelle dans la classe dérivée ne peuvent être plus lâches que celle de la définition la plus spécialisée de ses classes de base. En revanche, elles peuvent être plus restrictives.
En sortie d'une fonction virtuelle, les invariants de la classe dérivée et de la classe de base doivent être respectés.
Un transtypage d'un pointeur ou d'une référence depuis la classe de base vers la classe dérivée est souvent signe d'un problème de conception.
XXV. Un peu de lecture▲
Normes et livres :
- La norme (2003) : Programming languages C++ - ISO/IEC 14882:2003La norme C++
- Le draft C++0x : Working Draft, Standard for Programming Language C++C++0x, draft de septembre
- Le langage C++Le langage C++, de son inventeur, de Bjarne Stroustrup
- Conception et programmation orientées objetConception et programmation orientées objet, de Bertrand Meyer, de Bertrand Meyer.
- Design Patterns, Catalogue de modèles de conception réutilisablesDesign Patterns, Catalogue de modèles de conception réutilisables, des GoF, de Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Articles :
- Programmation par contrat, application en C++Programmation par contrat, application en C++, de Julien Blanc
- Open MultiMethods for C++Une évolution reportée ?, de Peter Pirkelbauer, Yuriy Solodkyy et Bjarne Stroustrup (2007)
- Présentation des classes de Traits et de Politiques en C++Présentation des classes de Traits et de Politiques en C++, de Alp Mestan (2007)
- « Pure Virtual Function Called »: An Explanation'Pure Virtual Function Called': An Explanation, de Paul S. R. Chisholm (2007)
- Le principe « ouvert/fermé »Le principe 'ouvert/fermé' , d'Emmanuel Deloget (2006)
- Never Call Virtual Functions during Construction or DestructionNever Call Virtual Functions during Construction or Destruction, de Scott Meyers (2005)
- Implicit VirtualImplicit Virtual, de Herb Sutter et Jim Hyslop, de Herb Sutter et Jim Hyslop (2005)
- AdaptationsAdaptations, de Herb Sutter et Jim Hyslop, de Herb Sutter et Jim Hyslop (2004)
- Virtually Misbehavin'. C++ implicit overriding at workVirtually Misbehavin'. C++ implicit overriding at work de Jim Hyslop et Herb Sutter (2004)
- VirtualityVirtuality, de Herb Sutter, de Herb Sutter (2001)
- Virtually YoursVirtually Yours, Jim Hyslop et Herb Sutter, de Jim Hyslop et Herb Sutter (2000)
- Multiple Inheritance for C++Multiple Inheritance for C++, de Bjarne Stroustrup (1999)
- The Open-Closed PrincipleO.C.P. de Robert C. Martin, de Robert C. Martin (1996)
XXVI. Remerciements▲
Je remercie Alp, r0d et Goten pour leurs relectures et leurs conseils avisés et ainsi que Luc Hermitte dont la compétence, l'étendue des connaissances et l'attention aux petits détails n'ont d'égales que la patience, la persévérance et la générosité à les partager. Sans eux imprécisions, approximations, oublis et erreurs seraient bien trop nombreux dans cet article.
Encore merci à dourouc05 et à koala01 pour la grand-mère et l'aurteaugraffe.
Enfin, d'une façon plus globale, je remercie les membres des forums de développez.com qui, par la qualité de leurs interventions, m'ouvrent constamment de nouvelles pistes de réflexion sur ma pratique de développement.