Discussion :

[oxyde356]

Petite question juste par curiosité ^^
Je sais qu'il est déconseillé de mettre des virtuals partout (nan sérieux ^^) parce que la génération de la vtable et l'appel des méthodes en est allongé. Dans le cas du polymorphisme il suffit de mettre le mot clé virtual a la méthode situé le plus haut dans la hiérarchie des classes pour que cela soit pris en compte par toutes les classes filles. 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
struct A
{
    virtual char test() {return 'A';}
};
 
struct B : public A
{
    char test() {return 'B';}
};
 
struct C : public B
{
    char test() {return 'C';}
};
 
int main(int argc, char* argv[])
{
	A* myObject1 = new A();
	A* myObject2 = new B();
	A* myObject3 = new C();
 
	printf("%c\n",myObject1->test());
	printf("%c\n",myObject2->test());
	printf("%c\n",myObject3->test());
 
	system("PAUSE");
 
	return 0;
}

Ecrit dans la console :

Code :

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

1
2
3
A
B
C

Bon vous allez me dire ouai où il veut en venir
Enfaite j'aimerais juste savoir si ça diminue les performances (même d'un micro-chouilla ^^) de mettre un virtual pour les méthodes de chaque classe fille alors que cette méthode est déjà définie virtual dans la classe mère.
Enfaite je vous pose cette question parce que j'ai l'habitude de faire ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct A
{
	virtual char test() {return 'A';}
};
 
struct B : public A
{
	virtual char test() = 0;
};
 
struct C : public B
{
	char test() {return 'C';}
};

(Voir même de mettre virtual char test()... pour la méthode de la class C, fin structure ça revient au même)
Alors que ce qui suit marche parfaitement mais look strange

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct A
{
	virtual char test() {return 'A';}
};
 
struct B : public A
{
	char test() = 0;
};
 
struct C : public B
{
	char test() {return 'C';}
};

Je suppose que le mieux c'est encore de mettre virtual en commentaire avant de déclarer la méthode qui n'a pas vraiment besoin de ce mot-clé, mais au final, si je met carrément le mot-clé virtual est ce que ça ralentit le programme a l'exécution ? à la compilation ?
Merci d'avance

[10_GOTO_10]

si je met carrément le mot-clé virtual est ce que ça ralentit le programme a l'exécution ?

Non. Je suppose que les exe générés seront identiques à l'octet près (fais un diff si tu veut en être certain)

à la compilation ?

Peut-être un milliardième de seconde plus lent (le temps de lire le mot-clé et de l'identifier). Et encore c'est pas sûr.

[Goten]

Le mot clef virtual est ajouté implicitement... Que tu le mettes ou non dans les classes filles il y'est.

[oxyde356]

Okay merci bien ^^
Et vous vous faites comment, vous l'écrivez en dur ? en commentaire ? pas du tout ? (petit sondage )

[Goten]

Je l'écris comme ça y'a pas d'ambiguïté. (si j'ai pas la visibilité sur la classe mère c'est utile de savoir lesquelles sont virtuelles...)

[oxyde356]

Ouep je suis d'accord c'est ce que je fais aussi, je l'avais déjà vu en commentaire aussi m'enfin si ça change rien autant le mettre.
Merci

[3DArchi]

Salut,
Extrait de Les fonctions virtuelles en C++ :

Les classes dérivées devraient utiliser le mot-clé virtual pour les fonctions définies comme virtuelles dans la classe de base.

Ici, il ne s'agit que de syntaxe et pas de code généré. Le vpointeur et la vtable sont produits dès lors qu'une fonction est virtuelle et/ou dès qu'il y a un héritage virtuel (même si ces 2 virtual n'ont rien à voir l'un l'autre).

[oxyde356]

Merci pour ces explications je vais donc continuer à suivre cette "norme" ^^

[koala01]

Salut,

Je voudrais en rajouter une couche en insistant, une fois de plus, sur le fait que la première qualité d'un code, avant même de faire ce que l'on attend de lui, est d'être facilement lisible et compréhensible par le programmeur qui devra le parcourir ou le modifier.

De ce point de vue, on peut réellement estimer que, même si quelque chose peut être fait de manière implicite, le code sera beaucoup plus compréhensible si ce qui est fait de manière implicite est... explicitement signalé.

Quand on sait que, de plus, cela ne prend pas énormément de temps de rajouter un terme dans le code source ( grâce, entre autres, à l'auto complétion ), on peut vraiment se dire que c'est un investissement qui en vaut la peine

[oxyde356]

Certes, surtout si ça ne coute rien ^^
Merci

[Alp]

Alors je vais peut-être passer pour un hérétique, mais j'ai avec le temps pris une habitude concernant l'écriture de 'virtual' dans des classes filles. Tout simplement, je ne remets 'virtual' dans une classe fille que si cette dernière pourrait être destinée à être héritée pour redéfinir la fonction membre en question. C'est à titre documentatif, rien de strict, mais c'est une habitude que j'ai développée.

Après, on pourra bien évidemment toujours hériter de ma classe fille et redéfinir, que j'ai mis virtual ou non. Mais disons que j'ai distingué les deux cas et que j'ai trouvé que ceci était un bon moyen.

[Lavock]

+1
Généralement, je vais encore "plus loin" : Je rajoute /* final */ devant la déclaration...

[3DArchi]

Alors je vais peut-être passer pour un hérétique, mais j'ai avec le temps pris une habitude concernant l'écriture de 'virtual' dans des classes filles. Tout simplement, je ne remets 'virtual' dans une classe fille que si cette dernière pourrait être destinée à être héritée pour redéfinir la fonction membre en question. C'est à titre documentatif, rien de strict, mais c'est une habitude que j'ai développée.

Après, on pourra bien évidemment toujours hériter de ma classe fille et redéfinir, que j'ai mis virtual ou non. Mais disons que j'ai distingué les deux cas et que j'ai trouvé que ceci était un bon moyen.

Pas d'accord. Je pense qu'il s'agit d'une question de lisibilité et d'auto documentation du code de mettre virtual dans les classes dérivées même si c'est implicite.
Je reprend le dernier biller d'Emmanuel Deloget qui résume bien mon sentiment (c'est moi qui souligne) :

Rappelons nous que le code que nous écrivons n'est pas destiné à la machine - mais aux autres programmeurs. La première qualité d'un code source, c'est sa lisibilité. Par définition, une information implicite est une information manquante - elle dégrade la lisibilité. Par conséquent, il est toujours préférable d'être explicite lorsqu'on écrit du code. Ajoutons donc ces 8 caractères - ce n'est pas comme si ça allait provoquer une usure prématurée de votre clavier...

[koala01]

Alors je vais peut-être passer pour un hérétique, mais j'ai avec le temps pris une habitude concernant l'écriture de 'virtual' dans des classes filles. Tout simplement, je ne remets 'virtual' dans une classe fille que si cette dernière pourrait être destinée à être héritée pour redéfinir la fonction membre en question. C'est à titre documentatif, rien de strict, mais c'est une habitude que j'ai développée.

Après, on pourra bien évidemment toujours hériter de ma classe fille et redéfinir, que j'ai mis virtual ou non. Mais disons que j'ai distingué les deux cas et que j'ai trouvé que ceci était un bon moyen.

J'aurais presque tendance à te demander comment tu arrives à déterminer, pour une classe fille donnée, s'il y a ou non une "chance" pour que, "plus tard", on fasse dériver une autre classe de celle-ci

Si tu le fais sur base des besoins exprimés au moment d'écrire ta classe fille, tu as une chance sur deux de te tromper, car... on ne sait jamais dire quelle évolution sera demandée dans le futur.

Si tu le fait de manière purement arbitraire, et que tu respecte cette décision par la suite, tu *risque* de limiter les évolutions futures.

Evidemment, je ne parle pas de *toi* en particulier ici, mais de toute personne qui serait au courent que "l'auteur a pour convention de ne pas écrire 'virtual' pour les fonctions dont il a estimé que la classe ne serait pas dérivée" qui serait susceptible d'utiliser ton code

Bon, je sais... je vais un peu loin, mais tout le monde sais que je ne peux m'en empêcher

[3DArchi]

+1
Généralement, je vais encore "plus loin" : Je rajoute /* final */ devant la déclaration...

Cette notion de final me perturbe. Je n'en vois pas trop l'intérêt comme évoqué de façon incidente dans cette discussion.

Malgré tout, les attributs C++0x introduiront cette notion de final :

Code :

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

1
2
3
4
5
6
struct B {
virtual void f [[ final ]] ();
};
struct D : B {
void f(); // ill-formed
};

[Alp]

Pas d'accord. Je pense qu'il s'agit d'une question de lisibilité et d'auto documentation du code de mettre virtual dans les classes dérivées même si c'est implicite.

C'est une question de goût, et surtout de convention. Les deux façons de faire ont leur utilité selon moi. J'exposais juste celle que j'utilise le plus souvent.

J'aurais presque tendance à te demander comment tu arrives à déterminer, pour une classe fille donnée, s'il y a ou non une "chance" pour que, "plus tard", on fasse dériver une autre classe de celle-ci

Justement, celles qui sont potentiellement destinées (ou celles pour lesquelles je n'ai aucune idée) à être dérivées plus tard ont le 'virtual' devant leurs fonctions membres.

Si tu le fais sur base des besoins exprimés au moment d'écrire ta classe fille, tu as une chance sur deux de te tromper, car... on ne sait jamais dire quelle évolution sera demandée dans le futur.

Je ne le base pas sur les besoins au moment de l'écriture de la classe fille, mais sur une imagination d'autant d'utilisations possibles de ma classe fille qui me viennent à l'esprit -- bref, j'anticipe tout ce qui pourrait de près ou de loin concerner cette classe fille. Quand je sais pas, je remets virtual.

Si tu le fait de manière purement arbitraire, et que tu respecte cette décision par la suite, tu *risque* de limiter les évolutions futures.

1/ Absolument pas, le 'virtual' ici est purement documentatif. Ca ne bloque rien. C'est juste self-documenting.
2/ Penses-tu vraiment que je (ou quelqu'un qui fait pareil) m'encombrerais avec ce genre de détails si c'était fait de manière arbitraire ?
De manière générale, ne sous-estime pas les personnes qui se soucient de ce genre de détail, on n'est plus au niveau de leur rappeler que la classe ou son éco-système est susceptible d'évoluer et doit être ainsi être aussi facile que possible à maintenir...

Le raisonnement qui m'a mené à cette pratique est le suivant : bon ok, si on met une fonction comme virtuelle quelque part dans une classe, elle le sera quoiqu'il arrive (à moins de la masquer, etc, bref on suppose une situation "normale") tout le long de la hiérarchie. On se retrouve donc avec, pour toute classe dérivant de la première, deux façons de redéfinir la fonction en question : avec ou sans "virtual" devant. Est-ce qu'on pourrait pas se servir du fait qu'il y a deux possibilités pour documenter deux "sémantiques" ? Par exemple "a de fortes chances d'avoir à être redéfinie" ou pas. Et voilà. Après, je ne dis pas que c'est la façon de faire. C'est une convention que j'ai, tout simplement.

[Lavock]

Exemple déjà écrit ici.

En gros, le parent à un virtuelle, car nécessaire. Dans le décorateur, tu n'as que 2 choix :

1. Soit tu met tout en protected (comme j'ai fait). Cela entraîne des
   responsabilités en plus pour la classe fille, expose à celle-ci un "détail d'implémentation" dont elle n'as pas à se préoccupé, MAIS cela lui permet un plus en souplesse (y compris la balle dans le pied).
   
2. Si je veux faire de l'idiot-proof, je met des "final" ou c'est nécessaire, et l'attribut qu'il faut en private. Pour rajouter de la souplesses, on pourra commencer une autre hiérarchie de fonction virtuelle.

Pour finir, en (1), je devrai rajouter dans la doc : en cas de redéfinition, penser à faire le ménage ou appeler la fonction parente. Malheureusement, si ce n'est pas fait (par inadvertance ou pire encore oO), même pas un warning...
En (2), rien à faire, cela va de soit.

Je sais pas si j'ai été claire. Sinon, dites le moi, je ferai un poste plus structuré.

[edit] Et au cas ou quelqu'un de (peu ?) saugrenu veuille développer, peut-être faudrait-il déplacé les posts relatifs sur un nouveau fil ?

[koala01]

<snip>"a de fortes chances d'avoir à être redéfinie" ou pas.

N'est-ce pas, justement, la sémantique du mot clé... virtual

Je sais bien qu'il n'est pas obligatoire, et je ne me concentre ici que sur le point de vue de "l'auto documentation" du code, mais...

Ecrire le mot clé virtual va prendre, quoi, deux secondes un peu plus si tu écris à deux doigts, un peu moins si tu est dactylographe de compétition... Sans compter l'auto-complétion qui te proposera le mot dés que tu aura écris virt... (c'est juste pour dire que... ca ne prend pas très longtemps )

Le fait est que, si une fonction est déclarée virtuelle dans une classe mère et non dans la classe fille, tu ne peux t'en rendre compte, à la lecture du code, que... si tu lis la définition de la classe mère...

Et tu sais aussi bien que moi que toutes les classes dérivées ne sont pas *forcément* définies dans le même fichier d'en-tête que leur classe mère.

A vrai dire, le fait qu'une classe fille soit définie dans le même fichier d'en-tête que sa classe mère fait même très clairement partie des cas exceptionnels :p

Cela implique que, si "n'importe qui" décide de faire dériver une de ses classes de la classe fille après en avoir "simplement" observé l'interface, il ne peut se faire une idée des fonctions qu'il peut redéfinir que... en lisant... l'implémentation de la classe mère, si c'est le "seul endroit" où le mot clé virtual apparait...

Et, bien que l'on puisse se poser un tas de questions sur une conception qui respecterait les "maximum minimaux admis" par la norme, tu peux avoir jusqu'à plusieurs centaines niveaux d'héritage...

Ca fait un fameux nombre de fichiers à ouvrir et à lire, si ce n'est QUE pour déterminer si on peut, effectivement, redéfinir une fonction ou non (étant entendu que, si elle est déjà déclarée dans la classe fille, elle est de facto déjà redéfinie au moins une fois)

Bien sur, tu me parlera sans doute de documentation... bla bla... génération automatique de doc qui fera sans doute apparaitre la virtualité de la fonction, bla bla...

Mais, si j'admets en effet qu'il est possible de retrouver "assez facilement" si une fonction est virtuelle ou non à la base, je ne peux m'empêcher d'estimer que c'est une sérieuse perte de temps que de devoir vérifier dans trois documents (quelle qu'en soit le contenu... un code source étant ici considéré commme un document ) si c'est bien le cas.

tu peux aussi m'objecter que, que ce soit toi (comprend: celui qui a écrit la classe fille) ou "quelqu'un d'autre" qui aurait décidé de faire dériver une classe de la classe fille, on peut "décemment" estimer qu'il y a au minimum "une connaissance de base" de l'organisation du code... sauf que...

Sauf que, entre le moment où tu as écrit la classe fille et le moment où tu peux décider d'en faire dériver une nouvelle classe ou, pour quelqu'un d'autre, entre le moment où il aura "assimilé" la documentatiion et celui où il voudra faire dériver une nouvelle classe de la classe fille, il peut se passer... à peu près tout et n'importe quoi... Y compris un temps plus qu'important, qui aura eu le malheur d'émousser les souvenirs

[Alp]

Comme je l'ai dit plus haut, je suis tout à fait d'accord avec vous 3DArchi et koala. Les deux "façons" sont valides.

C'est juste que savoir que telle fonction est virtuelle a moins (voir pas du tout selon les cas) primé sur "la documentation d'extensibilité" d'une classe fille, dans certains cas, de mon côté.

Je le rappelle pour la 3 ou 4ème fois, je ne suis pas en train d'imposer mon avis, juste de le présenter, au cas où cela puisse servir à quelqu'un.

[koala01]

Comme je l'ai dit plus haut, je suis tout à fait d'accord avec vous 3DArchi et koala. Les deux "façons" sont valides.

C'est juste que savoir que telle fonction est virtuelle a moins (voir pas du tout selon les cas) primé sur "la documentation d'extensibilité" d'une classe fille, dans certains cas, de mon côté.

Je le rappelle pour la 3 ou 4ème fois, je ne suis pas en train d'imposer mon avis, juste de le présenter, au cas où cela puisse servir à quelqu'un.

Ne prend pas le "tu" pour toi personnellement dans ce que j'ai écris...

Je n'ai utilisé ce pronom que par facilité, parce que c'est l'argumentation que je tiendrais vis à vis de quiconque essayerais de me convaincre