Virtualité

"Seb" a écrit:

Je me suis toujours posé la question suivante : pourquoi quand une méthode
est virtuelle, le mot "virtual" est optionnel lors de sa surcharge ?

à mon avis c'est parce que de toutes manières t'as pas le choix,
tu ne peux pas surcharger une virtual par une non-virtual ou vice-versa.

Personnellement, je trouve que le mettre dans le code est à la fois clair
et

pas difficile.

J'approuve. D'autant plus qu'il m'est arrivé de "virtualiser" ou
"dé-virtualiser" une méthode après coup et que cette habitude génère des
erreurs de compilation aux surcharges des erreurs de compilation "utiles"
pour attirer l'attention sur le fonctionnement des classes dérivées.

Maintenant il est possible que ce soit justement pour ça que la norme
n'oblige pas à répéter "virtual" : si tu utilises une classe de base faite
par un autre, tu n'es pas obligé de savoir si la méthode était déclarée
virtual ou pas. En fin de compte, les méthodes virtuelles ne servent "qu'à"
supporter le polymorphisme et on utilise souvent des classes supportant le
polymorphisme de manière non polymorphique...
--
Philippe Guglielmetti - www.dynabits.com

"Philippe Guglielmetti" <news@dynabits.com> a écrit dans le message
news: 3f94f2df$0$3657$5402220f@news.sunrise.ch

"Seb" a écrit:

Je me suis toujours posé la question suivante : pourquoi quand une
méthode est virtuelle, le mot "virtual" est optionnel lors de sa
surcharge ?

à mon avis c'est parce que de toutes manières t'as pas le choix,
tu ne peux pas surcharger une virtual par une non-virtual ou
vice-versa.

Personnellement, je trouve que le mettre dans le code est à la fois
clair et pas difficile.

J'approuve. D'autant plus qu'il m'est arrivé de "virtualiser" ou
"dé-virtualiser" une méthode après coup et que cette habitude génère
des erreurs de compilation aux surcharges des erreurs de compilation
"utiles" pour attirer l'attention sur le fonctionnement des classes
dérivées.

Maintenant il est possible que ce soit justement pour ça que la norme
n'oblige pas à répéter "virtual" : si tu utilises une classe de base
faite par un autre, tu n'es pas obligé de savoir si la méthode était
déclarée virtual ou pas. En fin de compte, les méthodes virtuelles ne
servent "qu'à" supporter le polymorphisme et on utilise souvent des
classes supportant le polymorphisme de manière non polymorphique...

Qu'entends-tu par "dé-virtualiser", il me semblait qu'une méthode virtuelle
reste et demeure virtuelle dans ses dérivations.

Sébastien

Seb wrote:

Je me suis toujours posé la question suivante : pourquoi quand une
méthode est virtuelle, le mot "virtual" est optionnel lors de sa
surcharge ? Personnellement, je trouve que le mettre dans le code est
à la fois clair et pas difficile.

Peut-être parce que ça ne fait que rendre plus clair et que ça n'apporte
rien d'utile au compilateur ?

Chris

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message news: bn3453$v00$1@news-reader5.wanadoo.fr

Seb wrote:

Je me suis toujours posé la question suivante : pourquoi quand une
méthode est virtuelle, le mot "virtual" est optionnel lors de sa
surcharge ? Personnellement, je trouve que le mettre dans le code est
à la fois clair et pas difficile.

Peut-être parce que ça ne fait que rendre plus clair et que ça
n'apporte rien d'utile au compilateur ?

Chris

Alors, pourquoi ne pas le rendre obligatoire ? C'est ça que je ne comprend
pas . . .

Sébastien

"Seb" a écrit:

J'approuve. D'autant plus qu'il m'est arrivé de "virtualiser" ou
"dé-virtualiser" une méthode après coup (...)
Qu'entends-tu par "dé-virtualiser", il me semblait qu'une méthode

virtuelle

reste et demeure virtuelle dans ses dérivations.

oui, je voulais dire lors du développement du soft, par exemple lorsqu'on
trouve un moyen de re-coder une ancienne méthode virtuelle de manière plus
efficace et non-virtuelle.
Si le programmeur (peut-être qqun d'autre, 2 ans avant...) a omis le
"virtual" devant les surcharges, on risque d'oublier de supprimer les
surcharges obsolète. Si on l'a mis, le compilateur nous le rappelle en
mettant le doigt dessus...
--
Philippe Guglielmetti - www.dynabits.com

Seb wrote:

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message news: bn3453$v00$1@news-reader5.wanadoo.fr

Seb wrote:

Je me suis toujours posé la question suivante : pourquoi quand une
méthode est virtuelle, le mot "virtual" est optionnel lors de sa
surcharge ? Personnellement, je trouve que le mettre dans le code
est à la fois clair et pas difficile.

Peut-être parce que ça ne fait que rendre plus clair et que ça
n'apporte rien d'utile au compilateur ?

Chris

Alors, pourquoi ne pas le rendre obligatoire ? C'est ça que je ne
comprend pas . . .

Parce que ça n'apporte rien au compilateur (je me répète). Si tu trouve que
c'est plus lisible, libre à toi de le mettre, mais pourquoi le rendre
obligatoire si celà n'apporte rien sémantiquement parlant ?

Chris

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message news: bn3f51$nfu$1@news-reader2.wanadoo.fr

Seb wrote:

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message news: bn3453$v00$1@news-reader5.wanadoo.fr

Seb wrote:

Je me suis toujours posé la question suivante : pourquoi quand une
méthode est virtuelle, le mot "virtual" est optionnel lors de sa
surcharge ? Personnellement, je trouve que le mettre dans le code
est à la fois clair et pas difficile.

Peut-être parce que ça ne fait que rendre plus clair et que ça
n'apporte rien d'utile au compilateur ?

Chris

Alors, pourquoi ne pas le rendre obligatoire ? C'est ça que je ne
comprend pas . . .

Parce que ça n'apporte rien au compilateur (je me répète).

Je pensais que tu posais une question dans ton mail précédent.


Si tu

trouve que c'est plus lisible, libre à toi de le mettre, mais
pourquoi le rendre obligatoire si celà n'apporte rien sémantiquement
parlant ?

Chris

D'accord, mais (sans faire de troll) j'ai du mal à me dire qu'un langage est
fait pour un compilateur (plutot que pour ceux qui le manipulent).

Merci, Sébastien

Seb wrote:

D'accord, mais (sans faire de troll) j'ai du mal à me dire qu'un
langage est fait pour un compilateur (plutot que pour ceux qui le
manipulent).

Disons que le compilateur reste le maillon le plus faible, n'ayant pas,
notemment, autant de facilités d'interpretations que l'être humain. Le
langage inclut un certain nombre de fonctionnalités pour le rendre plus
lisible par un être humain. Voudrais-tu imposer une indentation particulière
sous prétexte qu'elle améliore la lisibilité? Et quid pour des règles de
nommage des variables ? Si la seule chose qui est apportée, c'est une
meilleure lisibilité, c'est à l'individu de décider si il va s'en servir, et
du comment il va s'en servir.

Je pense qu'il y a des cas où le fait de rajouter virtual est utile,
notemment si la classe dont tu hérites (héritant elle même de la classe de
base déclarant les fonctions virtuelles) définit une nouvelle interface (en
rajoutant son lot de nouvelles fonctions virtuelles, voire en en déplaçant
certaines en private), mais je pense que ce cas n'est pas suffisemment
général pour imposer la répétition du virtual dans toutes les classes
dérivées...

Chris

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message news: bn3m9j$4ve$1@news-reader5.wanadoo.fr

Seb wrote:

D'accord, mais (sans faire de troll) j'ai du mal à me dire qu'un
langage est fait pour un compilateur (plutot que pour ceux qui le
manipulent).

Disons que le compilateur reste le maillon le plus faible, n'ayant
pas, notemment, autant de facilités d'interpretations que l'être
humain. Le langage inclut un certain nombre de fonctionnalités pour
le rendre plus lisible par un être humain. Voudrais-tu imposer une
indentation particulière sous prétexte qu'elle améliore la
lisibilité? Et quid pour des règles de nommage des variables ? Si la
seule chose qui est apportée, c'est une meilleure lisibilité, c'est à
l'individu de décider si il va s'en servir, et du comment il va s'en
servir.

Je pense qu'il y a des cas où le fait de rajouter virtual est utile,
notemment si la classe dont tu hérites (héritant elle même de la
classe de base déclarant les fonctions virtuelles) définit une
nouvelle interface (en rajoutant son lot de nouvelles fonctions
virtuelles, voire en en déplaçant certaines en private), mais je
pense que ce cas n'est pas suffisemment général pour imposer la
répétition du virtual dans toutes les classes dérivées...

Chris

Je comprend bien tous tes arguments : considère ce code :


class A {
public:
virtual void f() { cout << "Fonction de A" << endl; }
};

class B : public A
{
public:
static void f() { cout << "Fonction de B" << endl; }
};

class C : public B
{
public:
void f() { cout << "Fonction de C" << endl; }
};

int main(int, char**)
{
A* x;
A a;
B b;
C c;

a.f();
b.f();
c.f();

x = &a; x->f();
x = &b; x->f();
x = &c; x->f();
}

Je l'ai testé avec le compilateur Borland C++ 5.5. Le résultat est :

Fonction de A
Fonction de B
Fonction de C
Fonction de A
Fonction de A
Fonction de A

Par contre si ma classe est écrite :

class C : public B
{
public:
virtual void f() { printf("Fonction de Cn"); }
};

Le résultat est :

Fonction de A
Fonction de B
Fonction de C
Fonction de A
Fonction de A
Fonction de C

Sebastien

"Seb" a écrit >

Je l'ai testé avec le compilateur Borland C++ 5.5. Le résultat est :
ABCAAA, puis ABCAAC

VC6 et VC7 donnent ABCAAC dans les deux cas , ce qui signifie que la méthode
de C herite de l'attribut "virtual", et sauf erreur c'est le comportement
prévu par le standard.
Ce qui m'étonne plus, c'est que B puisse définir une méthode du même nom en
static, je savais pas que c'était permis, et à mon avis très ambigu...
--
Philippe Guglielmetti - www.dynabits.com