Discussion :

[Thierry Chappuis]

Bonjour,

Les mécanismes d'héritage et de polymorphismes sont liées en C++ à la définition de fonctions membres virtuelles. En Python, par exemple (car c'est par là que j'ai commencé) ou en Java, toutes les méthodes sont virtuelles et par conséquent la ligature est toujours dynamique (dynamic binding: le choix du type est effectué à l'exécution).

J'utilise beaucoup l'héritage et le polymorphisme dans la structuration de mon code et, par conséquent, je déclare toutes mes méthodes de classe avec le qualificateur "virtual". En revanche, je ne comprend pas très bien dans quelles situations nous avons intérêt à forcer une ligature statique. Est-ce une question de performance, le choix du type à l'exécution étant une opération trop gourmande en resources? Vos commentaires sur les bonnes pratiques à adopter en la matière sont les bienvenus.

Meilleures salutations

Thierry

[BigNic]

je ne sais pas si c'est propre ou non, mais moi cela m'arrive d'utiliser une ligature statique quand sur une classe qui est destiné à être dérivée je ve que des methodes ne puisse pas être redéfinies.
Exemple j'ai une famille d'objet A (A1, A2, A3, ....) tous dérive de A. Dans A j'ai une fonction qui calcul un Id selon certaine données de bases. Et je veut avoir la main sur l'algorithme de calcul de l'Id. Par contrte chacune des classes à sa propre façon de traiter ces données.
Il y a peut-être mieux comme solution pour faire ça, je suis pas expert en C++. Mais moi je procède comme cela.

[Gandalf]

Logiquement la conception te permet de savoir quelles fonction aurront à être redéfinies par les classes héritantes. N'imprte quelle classe n'est pas destinée à être heritée.

Les raisons de ne pas declarer une fonction virtual :
-les performances, un link dynamique c'est une indirection suplémentaire, donc une occasion de se rendre compte que ce que l'on cherche n'est pas dans le cache... De plus le compilo se voit interdit toute tentative d'optimisation type inline...
-La memoire puisque on ajoute une entrée dans une vTable (ou le mécanisme utilisé par le compilo)... ...sauf cas particulier (déjà vu) ce n'est pas vraiment limitant.

[Aurelien.Regat-Barrel]

Y'a une discution plus ou moins sur le sujet:
http://www.developpez.net/forums/viewtopic.php?t=457190

Comme l'a dit Gandalf c'est avant tout un problème de conception, pas de C++. Quand tu crées la classes, à priori tu décides si elle est destinée à être utilisée polymorphiquement ou non.

Une grande différence en C++ avec Java/Python c'est que tu peux manipuler un objet par valeur, après l'avoir instancié sur la pile. Dans ce cas la virtualité ne fonctionne pas, même avec virtual.
Et puis toutes les classes ne sont pas destinées à être dérivées, en particulier ces fameuses "value class". Pourquoi générer une vtable alors ?
Exemple avec les conteneurs de la STL:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
std::vector<int> v( 5 );
cout << v.size(); // virtual n'aurai pas de sens

Enfin la logique de C++ c'est "paye uniquement pour ce que tu demandes". Pense aux applis embarquées, si la virtualité n'est pas nécessaire dans ta hiérarchie de classes, pourquoi l'imposer ? Sur de petits processeurs embarqués ça peut êrte réellement pénalisant.

[HanLee]

Une grande différence en C++ avec Java/Python c'est que tu peux manipuler un objet par valeur, après l'avoir instancié sur la pile. Dans ce cas la virtualité ne fonctionne pas, même avec virtual.

Hum, moi j'ai une classe qui utilise une certaine sorte de polymorphisme.

C'est à dire que tu considères une classe de base A, qui a des méthodes auxquelles j'y touche pas, et ces méthodes définies une fois pour toutes appellent des autres méthodes, auxquelles j'ai rajouté le mot clé virtual.

Je construis ensuite une nouvelle classe B qui dérive directement de A.
Les méthodes virtuelles de A sont ensuite surchargées dans la classe B.

Quand je crée un objet de la classe B directement avec la pile, et que j'appelle les méthodes ayant été définies pour de bon (au niveau de la classe de base A), eh bien si je n'avais pas mis le mot-clé virtual, les nouvelles méthodes surchargées dans la classe B n'auraient pas été appelées, mais seulement celles de A.

C'est pas du polymorphisme statique ça, avec pile ?

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
#include <iostream>
 
class A
{
	virtual void DoSomething()
	{
		std::cout << "C'est la classe A qui parle ici !\n";
	}
 
public:
	void Action()
	{
		DoSomething();
	}
};
 
class B : public A
{
	void DoSomething()
	{
		std::cout << "C'est la classe B qui parle ici !\n";
	}
};
 
 
int main()
{
	A a;
	B b;
 
	a.Action();
	b.Action();
 
	return 0;
}

Resultat :

C'est la classe A qui parle ici !
C'est la classe B qui parle ici !

Et si j'avais enlevé virtual, ça ne marcherait pas :

C'est la classe A qui parle ici !
C'est la classe A qui parle ici !

Cet aspect du polymorphisme est rarement abordé j'trouve.

[Médinoc]

Erreur: Avec sans le virtual, ton exemple marche aussi.

C'est en les utilisant en tant que "référence sur A" ou "pointeur sur A" que le virtual a une signification...

Edit: Note pour plus tard : Penser à me racheter des yeux

[Luc Hermitte]

En ce qui me concerne, les virtuals sont là en conséquence des choix de design. Si il apparait qu'un comportement doit être ajusté à un point précis, alors la réalisation de ce point précis (de variabilité) va reposer sur un polymorphisme d'inclusion (à base de fonction membre virtuelle en C++) dans le cadre de hiérarchies de classes.

Tout mettre en virtual laisse sous entendre que tout peut être supplanté sans risques. Ce qui est loin d'être vrai. Plus souvent, je trouve que des refactorings plus profonds sont nécessaires pour étendre des traitements qui n'avaient pas précisément anticipé l'évolution. Le virtual par défaut n'a donc plus grand intérêt.

Soit en ce qui me concerne => pas virtual par défaut, virtual si le design me dit que j'en ai besoin. L'amélioration de performance est la cerise sur le gâteau. Cf un autre fil, plutôt récent sur l'impact de la liaison tardive sur les performances.

Des incompatibilités inhérentes avec les classes à sémantique de valeurs ont été rapellées par mes petites camarades, je n'y reviens pas. Il n'y a pas ici de règle absolu, mais par défaut, ces choses là ne se combinent pas toutes seules sans la moindre précaution.

[HanLee]

Erreur: Avec sans le virtual, ton exemple marche aussi.

C'est en les utilisant en tant que "référence sur A" ou "pointeur sur A" que le virtual a une signification...

Non, sans virtual, l'exemple ne marche pas.

Testé avec Visual C++ 2005, et Dev-C++.

[Thierry Chappuis]

Merci beaucoup pour vos réponses très intéressantes. Pour résumer, il semble que vous êtes d'accord pour utiliser virtual seulement si la conception l'impose, et en particulier, il semble parfois souhaitable de ne pas laisser l'utilisateur redéfinir certaines méthodes dans ses classes dérivées. Par ailleurs, une utilisation systématique des méthodes virtuelles semble pénalisante du point de vue des performances sur un petit système embarqué.

Meilleures salutations

Thierry

[Jean-Marc.Bourguet]

Erreur: Avec sans le virtual, ton exemple marche aussi.

C'est en les utilisant en tant que "référence sur A" ou "pointeur sur A" que le virtual a une signification...

Et this est un pointeur... :-)

[Médinoc]

C'est moi qui me suis complètement gouré, j'avais tapé a.DoSomething() au lieu de a.action()...

Évidemment, sans virtual, A::Action() appelle A:oSomething()...
En fait, c'est un peu le comportement attendu... Sauf pour un programmeur java...