Les fonctions virtuelles en C++ : Types statiques et types dynamiques

Revenons sur les fonctions virtuelles pures brièvement évoquées en début d'article. Syntaxiquement, une fonction virtuelle pure est une fonction virtuelle à laquelle est accolée =0 à la fin de la déclaration :

struct base
{
   void pure_function()=0;
   virtual ~base(){}
};

Une fonction virtuelle pure définit une classe abstraite. Une classe abstraite ne peut pas être instanciée :

struct abstract
{
   virtual void pure_function()=0;
   virtual ~abstract(){}
};
int main()
{
   abstract b; // erreur
   return 0;
}

Une classe définit une fonction virtuelle pure quand elle souhaite indiquer que les classes dérivées DOIVENT spécialiser cette fonction virtuelle pour pouvoir être instanciée. Une classe dérivant d'une classe abstraite et spécialisant les fonctions virtuelles pures est appelée classe concrète. Une classe concrète peut alors être instanciée :

struct abstract
{
   virtual void pure_function()=0;
   virtual ~abstract(){}
};
struct concrete : public abstract
{
   virtual void pure_function() {}
};
int main()
{
   concrete b; // OK
   return 0;
}

Comme les fonctions virtuelles pures doivent être spécialisées par les classes concrètes, il est possible de ne pas définir d'implémentation pour une fonction virtuelle pure dans la classe abstraite :

struct abstract
{
   virtual void pure_function()=0; // pas de définition
   virtual void function(); // doit être définie
   
   virtual ~abstract(){}
};
struct concrete : public abstract
{
   virtual void pure_function() {} // la définition dans la classe concrète peut suffire
                                   // A noter que la spécialisation de la fonction
                                   // dans la classe concrète DOIT être définie
   virtual void function(){} // la définition dans la classe ne suffit pas pour
                             // une classe virtuelle non pure. Elle doit aussi être définie dans la 
                             // classe de base
};

int main()
{
   concrete c;
   return 0;
}//Erreur à l'édition de lien : abstract::fonction non définie

Enfin, si une classe abstraite veut définir une fonction virtuelle pure alors elle doit le faire en dehors de la déclaration de la fonction :

struct abstract
{
   virtual void pure_function()=0;
   
   virtual ~abstract(){}
};
void abstract::pure_function()
{// définition de la fonction
}

Visual C++ compile une fonction virtuelle pure définie dans la classe abstraite, mais c'est un écart à la norme. Le code suivant compile avec Visual C++, mais pas GCC :

struct abstract
{
   virtual void pure_function()=0
   {// Compile avec Visual C++, mais pas avec GCC
   }
   
   virtual ~abstract(){}
};

S'il est impossible d'instancier une classe abstraite, rien en revanche n'interdit d'utiliser un pointeur ou une référence vers une classe abstraite :

struct abstract
{
   virtual void function()=0;
   
   virtual ~abstract(){}
};
struct concrete : public abstract
{
   virtual void function(){}
};

int main()
{
   concrete c;
   abstract &ra = c;
   abstract *pa = new concrete; // On n'oublie pas notre destructeur virtuel...
   delete pa;
   return 0;
}

Enfin, les plus attentifs auront déjà déduit cette conséquence de l'impossibilité d'instancier une classe abstraite :

En effet, le type dynamique est le type de l'objet réellement utilisé à l'exécution du programme. Or ne pouvant instancier de classe abstraite, l'objet réellement utilisé sera toujours une classe concrète dérivée de la classe abstraite. Nous avons vu que les deux seuls cas échappant à cette règle sont le constructeur et le destructeur dans lesquels types dynamique et statique coïncident.
En revanche, le type statique d'une variable peut être celui d'une classe abstraite. this à l'intérieur d'une fonction de la classe abstraite est un cas trivial où le type statique est celui de la classe abstraite. Mais il en va de même pour les références et les pointeurs de classe abstraite :

struct abstract
{
   virtual void pure_function()=0;
   void a_function()
   {// type statique == abstract
    // type dynamique == type de la classe concrète dérivée
   }
   
   virtual ~abstract() {}
};
struct concrete : public abstract
{
   virtual void pure_function() {}
};
int main()
{
   concrete b;
   abstract &rb = b; // le type statique de rb est abstract, le type dynamique est concrete
   abstract *pb = &b; // le type statique de pb est abstract, le type dynamique est concrete
   return 0;
}

L'appel d'une fonction virtuelle pure suit toujours les mêmes règles que celle d'une fonction virtuelle classique. Il est possible de l'appeler depuis n'importe quelle autre fonction :

#include <iostream>

struct base
{
   void call_function()
   {
      function();
   }
   virtual void function()=0;
   
   virtual ~base(){}

};
struct derived :public base
{
   virtual void function()
   {
      std::cout<<"derived::function\n";
   }
};

int main()
{
   derived d;
   std::cout<<"\nappels pour derived d; : \n";
   d.function();
   d.call_function();

   base &rd = d;
   std::cout<<"\nappels pour base &rd = d; : \n";
   rd.function();
   d.call_function();

   return 0;
}

La résolution de l'appel utilise le type dynamique pour choisir la fonction à dérouler. Il s'agit donc de la version la plus spécialisée dans la classe la plus dérivée.

Comme nous avons vu que le type dynamique d'un objet ne peut jamais être celui d'une classe abstraite, il est aisé de comprendre la conclusion suivante :

Le seul moyen pour que cette définition soit appelée est de forcer l'appel en indiquant explicitement la classe abstraite dans l'appel :

#include <iostream>

struct base
{
   virtual void function() const =0;
   virtual ~base(){}
};
void base::function() const
{
   std::cout<<"Appel de base::function\n";
}

struct derived :public base
{
   virtual void function() const
   {
      std::cout<<"Appel de derived::function\n";
      base::function(); // appel explicite de la classe parent
   }
};

void call_function(base const &b_)
{
   b_.function();
}

int main()
{
   derived d;
   call_function(d);
   return 0;
}

Si la fonction virtuelle pure de la classe abstraite de base n'a pas de définition, alors la compilation échoue sur une erreur de lien :

#include <iostream>

struct base
{
   virtual void function() const =0;
   
   virtual ~base(){}
};

struct derived :public base
{
   virtual void function() const
   {
      std::cout<<"Appel de derived::function\n";
      base::function(); // appel explicite de la classe parent : erreur de lien
   }
};

void call_function(base const &b_)
{
   b_.function();
}

int main()
{
   derived d;
   call_function(d);
   return 0;
}

Le code précédent produit une erreur de lien.

On peut se demander pourquoi devrait-on avoir besoin de définir une fonction virtuelle pure dans la classe abstraite si elle n'est jamais implicitement appelée par la résolution dynamique. Mon opinion est qu'une telle définition est souvent une erreur de conception. Voyons les différents cas qui semblent nécessiter une définition dans la classe abstraite et regardons comment les contourner :

• La classe de base propose un comportement par défaut : si tel est le cas, alors c'est que la classe dérivée peut très bien n'utiliser que ce comportement par défaut et ne pas avoir de comportement spécifique. Dans ce cas, la fonction peut être uniquement virtuelle (pas pure), les classes dérivées n'ayant pas de comportement spécifique ne spécialisent pas la fonction virtuelle.

  Avec une fonction virtuelle pure :

  Une autre approche :

  Une fonction virtuelle pure avec un comportement par défaut : pour quoi faire ? Sélectionnez #include <iostream> struct base { virtual void function()=0; virtual ~base(){} }; void base::function() { std::cout<<"Comportement par defaut\n"; } struct derived :public base { virtual void function() { std::cout<<"Comportement specialise\n"; } }; struct derived_2 :public base { virtual void function() { base::function(); } };

  Une fonction virtuelle suffit ! Sélectionnez #include <iostream> struct base { virtual void function() { std::cout<<"Comportement par defaut\n"; } virtual ~base(){} }; struct derived :public base { virtual void function() { std::cout<<"Comportement specialise\n"; } }; struct derived_2 :public base { // pas de spécialisation de function : utilise la version par défaut };

• La classe de base factorise une partie du comportement : je préfère alors sortir le comportement factorisé dans une autre fonction spécifique protégée et que seules les classes dérivées peuvent alors appeler. Les responsabilités sont séparées et le code est plus clair.

  Avec une fonction virtuelle pure :

  Une autre approche :

  Une fonction virtuelle pure avec un comportement factorisé : pour quoi faire ? Sélectionnez #include <iostream> struct base { virtual void function()=0; virtual ~base(){} }; void base::function() { std::cout<<"Comportement frequent\n"; } struct derived :public base { virtual void function() { std::cout<<"Comportement specialise ET \n"; base::function(); } }; struct derived_2 :public base { virtual void function() { std::cout<<"Comportement specialise ET \n"; base::function(); } }; struct derived_3 :public base { virtual void function() { std::cout<<"Comportement specialise uniquement \n"; } };

  Une fonction virtuelle suffit ! Sélectionnez #include <iostream> struct base { virtual void function()=0; protected : void specific_recurrent_point() { std::cout<<"Comportement frequent\n"; } virtual ~base(){} }; struct derived :public base { virtual void function() { std::cout<<"Comportement specialise ET \n"; specific_recurrent_point(); } }; struct derived_2 :public base { virtual void function() { std::cout<<"Comportement specialise ET \n"; specific_recurrent_point(); } }; struct derived_3 :public base { virtual void function() { std::cout<<"Comportement specialise uniquement \n"; } };

• Une partie doit toujours être déroulée lors de l'exécution de la fonction : si une partie doit toujours être déroulée, et que cette partie est dans le code d'une fonction virtuelle, alors on prend le risque qu'un jour une classe dérivée 'oublie' de faire l'appel vers la classe de base. Ce genre de bug arrive vite dès qu'un projet est conséquent : on oublie ce petit détail lorsqu'on doit intervenir dans l'urgence dans le code plusieurs mois après son développement, un nouveau venu n'aura pas forcément l'information (surtout si l'héritage est complexe, même une documentation dans le code pourra échapper au développeur). Je préfère pour plus de tranquillité définir une fonction non virtuelle qui déroule le code qui doit être appelée et utilise une fonction virtuelle pure et sans définition pour les parties qui doivent être spécialisée (voir le pattern N.V.I.) :

struct base
{
   virtual void function()=0;

   virtual ~base(){}
};
void base::function()
{
   std::cout<<"Comportement necessaire\n";
}

struct derived :public base
{
   virtual void function()
   {
      std::cout<<"Comportement specialise ET \n";
      base::function();
   }
};

struct derived_2 :public base
{
   virtual void function()
   {
      std::cout<<"Comportement specialise ET \n";
      base::function();
   }
};

#include <iostream>

struct base
{
   void function()
   {
      pre_function();
      do_function();
      post_function();
   }

   virtual ~base(){}

   private:
   void pre_function()
   {
      std::cout<<"Comportement necessaire avant\n";
   }
   void post_function()
   {
      std::cout<<"Comportement necessaire apres\n";
   }
   virtual void do_function()=0;

};

struct derived :public base
{
   private :
   virtual void do_function()
   {
      std::cout<<"Comportement specialise\n";
   }
};

struct derived_2 :public base
{
   virtual void do_function()
   {
      std::cout<<"Comportement specialise 2\n";
   }
};

Il existe une seule bonne raison de déclarer une fonction virtuelle pure avec une définition : un destructeur virtuel pur.

Le destructeur comme toute fonction virtuelle peut être une fonction virtuelle pure. La différence est qu'un destructeur virtuel pur DOIT avoir une définition. En effet, le destructeur étant toujours appelé lors de la destruction de l'objet, il doit avoir un corps même vide. Ou dit autrement, les destructeurs doivent toujours avoir une définition qu'ils soient virtuels ou non, cette définition étant soit donnée par le code soit implicitement construite par le compilateur dans le cas des destructeurs implicites.
Définir un destructeur virtuel pur est parfois la seule façon de définir une classe abstraite si les autres fonctions n'ont pas lieu d'être virtuelle pure. Comme la définition d'un corps est obligatoire et que son appel est implicite, cela ne pose pas de problème.

struct base
{
   virtual ~base()=0; // la classe est abstraite, car le destructeur est virtuel pur
};
base::~base()
{ // la définition du destructeur est obligatoire même s'il est pur.
}

struct base
{
   virtual ~base()=0;
};
base::~base()=default; // définition à l'extérieur de la classe

La norme est catégorique pour les appels des fonctions virtuelles pures dans le constructeur ou le destructeur :

Cette règle tombe sous le bon sens. Rappelez-vous une fonction virtuelle pure peut ne pas avoir de définition dans une classe abstraite. Dès lors, la règle pour les fonctions virtuelles stipulant que c'est la fonction définie dans le constructeur en cours de construction qui est appelée ne peut être étendue puisque cette définition peut ne pas exister. Afin de ne pas créer d'ambiguïté, la règle ci-dessus qui a l'avantage de la simplicité a été introduite dans la norme : l'appel d'une fonction virtuelle pure dans une classe abstraite provoque un comportement indéterminé.
Si cette règle a l'avantage de la simplicité, elle a l'inconvénient qu'un comportement indéterminé peut révéler des surprises. Regardons ainsi comment cette règle est mise en œuvre dans 2 compilateurs différents : Visual C++ et GCC.

Prenons un premier exemple simple : une fonction virtuelle pure sans définition dans la classe abstraite appelée directement dans le constructeur (le comportement est le même si l'appel a lieu dans le destructeur)

#include <iostream>
struct base
{
   base()
   {
      do_init();
   }
   virtual void do_init()=0;
   virtual ~base(){}
};

struct derived : public base
{
   derived()
   {
   }
   virtual void do_init()
   {
      std::cout<<"derived::do_init\n";
   }
};
int main()
{
   derived d;
   return 0;
}

À la compilation, Visual C++ est muet comme une carpe, mais GCC nous met la puce à l'oreille :

warning : abstract virtual 'virtual void base::do_init()' called from constructor

Mais le point le plus intéressant et sur lesquels les deux compilateurs se rejoignent est l'édition de lien : Visual C++ et GCC provoquent une erreur de lien :

Visual C++ : symbole externe non résolu « public: virtual void __thiscall base::do_init(void) »
GCC : undefined reference to `base::do_init()'

Il est donc impossible de produire un code avec un tel comportement indéterminé !
Cette erreur à l'édition de lien se comprend au regard de l'optimisation des appels des fonctions virtuelles dans le constructeur (resp. destructeur). Cette optimisation permet une résolution statique de l'appel par le compilateur. Il insère donc tout simplement un appel vers base::do_init dans le constructeur. Or comme cette fonction n'est définie nulle part, l'édition de lien échoue. C'est bien un appel vers base::do_init qui est tenté et non vers derived::do_init,car la règle stipule bien que le compilateur doit considérer le constructeur en cours d'exécution.

Un second exemple plus embêtant. Considérons maintenant l'appel indirect d'une fonction virtuelle pure dans le constructeur (comme toujours, le comportement est le même dans le destructeur) :

#include <iostream>
struct base
{
   base()
   {
      init();
   }
   void init()
   {
      do_init();
   }
   virtual void do_init()=0;
   virtual ~base(){}
};

struct derived : public base
{
   derived()
   {
   }
   virtual void do_init()
   {
      std::cout<<"derived::do_init\n";
   }
};
int main()
{
   derived d;
   return 0;
}

Effet démo garanti : ce code provoque une erreur à l'exécution avec les deux compilateurs. Ils ont l'amabilité d'indiquer l'erreur de façon très explicite :

GCC : pure virtual method called
Visual C++ : R6025
- pure virtual function call

L'appel indirect d'une fonction virtuelle pure dans un constructeur ou un destructeur d'une classe abstraite provoque une erreur à l'exécution avec Visual C++ et GCC.

Un troisième exemple : appelons directement une fonction virtuelle pure dans une classe abstraite, mais en ayant défini cette fonction :

#include <iostream>
struct base
{
   base()
   {
      do_init();
   }
   virtual void do_init()=0;
   virtual ~base(){}
};
void base::do_init()
{
   std::cout<<"base::do_init\n";
}

struct derived : public base
{
   derived()
   {
   }
   virtual void do_init()
   {
      std::cout<<"derived::do_init\n";
   }
};

int main()
{
   derived d;
   return 0;
}

Surprise ! Ce code compile avec Visual C++ et GCC (modulo l'avertissement de l'appel d'une fonction virtuelle pure dans le constructeur) sans problème et s'exécute sans planter.
L'explication est analogue à notre premier exemple : les compilateurs ont résolu l'appel statiquement et donc inséré un appel directement vers base::do_init. Cette fonction étant cette fois-ci bien définie, l'édition de lien a pu aboutir. À l'exécution, la fonction a tout simplement été déroulée.

Enfin, un dernier exemple : considérons l'appel indirect d'une fonction virtuelle pure avec une définition dans la classe abstraite.

#include <iostream>
struct base
{
   base()
   {
      init();
   }
   void init()
   {
      do_init();
   }
   virtual void do_init()=0;
   virtual ~base(){}
};
void base::do_init()
{
   std::cout<<"base::do_init\n";
}

struct derived : public base
{
   derived()
   {
   }
   virtual void do_init()
   {
      std::cout<<"derived::do_init\n";
   }
};

int main()
{
   derived d;
   return 0;
}

Ici, nous retrouvons le comportement observé dans le second exemple à savoir un plantage à l'exécution indiquant l'appel d'une fonction virtuelle pure dans le constructeur :

GCC : pure virtual method called>
Visual C++ : R6025
- pure virtual function call

Soit pour résumer, nous avons avec Visual C++ et GCC les comportements suivants pour un appel de fonction virtuelle pure dans un constructeur ou un destructeur :

Ceci avait pour seul but de montrer qu'un comportement déclaré comme indéterminé par la norme se révèle effectivement varié et subtil. Vos codes ne doivent pas transiger avec cette règle élémentaire :

À partir du moment où une fonction virtuelle pure reçoit une spécialisation dans une classe concrète, alors elle se comporte comme une fonction virtuelle classique. La fonction appelée est celle du constructeur en train de s'exécuter et non de l'objet en train d'être construit :

#include <iostream>
struct base
{
   base()
   {}
   void init()
   {
      do_init();
   }
   virtual void do_init()=0;
   virtual ~base(){}
};

struct derived : public base
{
   derived()
   {
      init();
   }
   virtual void do_init()
   {
      std::cout<<"derived::do_init\n";
   }
};

struct derived_2 : public derived
{
   derived_2()
   {
      init();
   }
   virtual void do_init()
   {
      std::cout<<"derived_2::do_init\n";
   }
};

int main()
{
   derived_2 d;
   return 0;
}

Si init est bien une fonction de la classe abstraite base, l'appel effectif à init se fait bien dans le constructeur des classes concrètes derived et derived_2. Il ne faut pas tenir compte de la classe qui fait l'appel, mais bien du constructeur (resp. destructeur) qui est en train de se dérouler.