pb surcharge et heritage

Version imprimable

10/08/2007, 00h16
NiamorH

pb surcharge et heritage
Bonjour,

Je suis dans la configuration suivante :
Code:

1 2 3 4 5 6 7 8 9 10 class A { void func(); virtual void func( int ); }; class B : public A { virtual void func( int ); };
J'ai une erreur de compil sous VS2005 (pas assez de parametres) lorsque j'appelle :

Code:

b->func();

Je suis obligé d'écrire :

Code:

static_cast<A*>(b)->func();

Pourquoi ?
10/08/2007, 01h04
loufoque

Il faut mettre using A::func dans la définition de B.
10/08/2007, 01h12
JolyLoic

Tout d'abord, le compilateur doit chercher les fonctions qui participent à la surcharge. Pour ça, il considère juste le nom des fonctions, sans leurs paramètres.

Quand il ne trouve pas de fonction dans une classe, il a le droit de regarder dans la classe de base. S'il en trouve non.

Donc, ici, il trouve une fonction dans ta classe, et une seule. Du coup il ne va pas cherché dans la classe de base (on dit ici que la fonction est "cachée"). Ensuite, il résoud la surcharge : Simple, il y a une seule fonction. Mais celle ci ne va pas : Erreur.

Maintenant, sur le pourquoi de ces règles ? Je crois que faire autrement aurait pu causer des surprises, mais je ne sais plus trop lesquelles.

Effectivement ça marche bien comme ça :
Code:

1 2 3 4 5 6 7 8 9 class B : public A { public: using A::func; virtual void func( int ) {} B(void); ~B(void); };
Merci à vous deux ;)

Salut,

Ceci dit, l'un des premiers conseils que l'on puisse donner est que, si on doit déclarer une fonction membre virtuelle dans une classe, le mieux est de déclarer toutes les fonctions membres de cette classe comme virutelles.

De cette manière, tu éviteras énormément de problèmes, entre autres dans le cadre d'une fonction surchargée dont la surcharge n'apparaît pas dans une des classes:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class A { public: A(); virtual ~A(); virtual void fonct(); virtual void fonct(int i); /* ca, c'est la seule fonction redéfinie */ /*...*/ }; class B: public A { public: B(); virtual ~B(); virtual void fonct(int i); };
Tant qu'à créer une vtable, autant y mettre toutes les fonctions ;)

14/08/2007, 17h14
JolyLoic

Citation:

Envoyé par koala01

Ceci dit, l'un des premiers conseils que l'on puisse donner est que, si on doit déclarer une fonction membre virtuelle dans une classe, le mieux est de déclarer toutes les fonctions membres de cette classe comme virutelles.

Bof...

Pour moi, le mot clef virtuel est un indice important pour la personne devant dériver d'une classe, il indique quels sont les (rares en général) points de customisation prévus par le créateur de la classe initiale. Tout mettre virtuel me semble être de l'obfuscation. Il ne m'arrive par exemple quasiment jamais de mettre une fonction publique virtuelle.

Pour l'argument : "tant qu'à... ", je ne suis pas forcément d'accord non plus, car tous les appels de fonctions vont devoir passer par l'indirection de la vtable, et je ne suis pas certain que le compilateur puisse optimiser cette pessimisation dans tous les cas.
14/08/2007, 17h43
Alp

Oui +1 pour Loïc.

Lorsque l'on dérive une classe de la première, on sait quelles fonctions redéfinir grâce au fait qu'elles soient préfixées par "virtual".

Je ne sais pas si passer systématiquement par la vtable pour chaque fonction membre est une bonne chose, moi non plus ... Je n'ai jamais testé, car l'idée paraît étrange de prime abord :aie:
14/08/2007, 18h16
koala01

Et pourtant, c'est un conseil que l'on retrouve dans de nombreux livres qui savent pourtant très bien de quoi ils parlent...

Ainsi, dans le chapitre 17.0 de "thinking in C++", c'est clairement le but du point n°28 des grandes lignes de conduites.

La traduction se trouve =>ici<=
15/08/2007, 00h12
Luc Hermitte

Légèrement contraire à mon expérience.
Soit on prévoit le point de variabilité dynamique et les fonctions se supplantent en toute transparence.
Soit on met des virtual parce-qu'on-le-vaut-bien, et la supplantation n'est absolument pas transparente, un refactoring plus profond est systématiquement nécessaire.

Ma conclusion : à quoi bon se mentir ?

En références ?
* Loïc a fait référence au NVI pattern (C++ Coding standards, item 39)
* Et puisque l'on parle de Bruce Eckel, je suis tombé sur ça sur artima : http://www.artima.com/intv/nonvirtual.html
* Un autre auteur de qualité qui s'exprime
* Je n'ai pas le D&E C++, mais je ne serai pas surpris d'y trouver un truc du genre.
15/08/2007, 00h19
Alp

Citation:

Envoyé par Luc Hermitte

Légèrement contraire à mon expérience.
Soit on prévoit le point de variabilité dynamique et les fonctions se supplantent en toute transparence.
Soit on met des virtual parce-qu'on-le-vaut-bien, et la supplantation n'est absolument pas transparente, un refactoring plus profond est systématiquement nécessaire.

Je suis d'accord avec ce point de vue.
Pour ma part, je trouve bien plus logique de penser le design de classes comme cela plutôt que du TOR (Tout Ou Rien), et puis bien que ça ne coute pas beaucoup plus de tout mettre virtuel, ça coute quand même plus!

De plus, un animal par exemple a un âge, et l'on renvoie son âge via une fonction non virtuelle. On ne va pas renvoyer son âge+2 dans une classe fille.

Ou bien, il y a les "interfaces" Java, qui correspondent à des classes où toutes les fonctions membres sont virtuelles, ...

Ma conclusion : à quoi bon se mentir ?
15/08/2007, 04h04
koala01

J'ai beau être d'accord, dans le fond, avec vous...il n'empêche que...

A partir du moment où la virtualité d'une fonction (ou peut-être la non virtualité d'une fonction) pose problème, la solution "la plus simple" - à défaut d'être la meilleure - est de rendre toutes les fonctions d'une classe virtuelles, quitte à supprimer "a posteriori" la virtualité sur les fonctions qui n'en ont réellement pas besoin...

Cela rentre, en quelque sorte dans le conseil "faites quelque chose qui fonctionne, améliorez si c'est nécessaire par la suite" ;)

Je reconnais volontiers que l'optique n'est peut être pas la meilleure, par le surplus de travail qu'elle peut représenter et par le fait de se "mentir", mais d'un autre coté, il faut reconnaître qu'elle fournit un manière efficace d'être sur "que cela fonctionne"
15/08/2007, 09h07
Luc Hermitte

Rajouter un "virtual" ne coute rien comparé au prix de la réflexion nécessaire à mener et de la refactorisation qui s'imposera bien souvent.

NB: pour l'accesseur getAge() à la propriété Age, regardez toutes les implications. Si on devait introduire des proxys pour acceder à des objets distant, getAge() devra être virtuelle. Mais au niveau d'une classe d'interface parente qui n'existe pas encore (vu que l'on ne va pas se trimballer d'attribut d'implémentation m_age dans l'interface) => refactoriring.

Des cas plus classiques que je rencontre, c'est des fonctions qui font 3 ou 4 choses relativement distinctes -- pas toujours du bon-design-inside. Et puis, on se rend compte qu'il faut spécialiser le second traitement. Avoir la fonction virtuelle n'aurait strictement rien apporté vu qu'il faut spécialiser un sous traitement. => refactoring de type "Extract method" pour appliquer le DP "template method". Si on a pensé dès le début de la conception à ouvrir ce point de variabilité d'exécution, c'est parfait : on a déjà f() non virtuelle, et do_f2() qui est virtuelle-privée.

Revenir en arrière sur une virtualité mal pensée m'a pour l'instant couté plus cher dans des phases de maintenance refactorisante que le contraire. Quand tu vois un virtual et que tu sais que tu as des changements profond à faire dans une fonction, il faut chercher à tous les niveaux les pre- et post-conditions d'utilisation de cette fonction pour s'assurer de ne rien casser.