Discussion :

[PhiphyL]

Titre bizarre, laissez-moi l'expliciter : les partiels arrivant bientôt (en fait le Java/C++ c'est demain), j'ai déniché les sujets partiels de l'année dernière et il semblerait que ce soit une excellente base pour bosser.

La partie Java c'est bon, par contre le C++ est un peu plus chaud, on l'a mal étudié et couplé au Java c'est facile de s'emmêler. Je vous demande donc humblement un coup de main pour résoudre les exercices de cette feuille :
http://phiphyl.free.fr/c++1.jpg
Ca pourrait sauver la moyenne de pas mal de monde ^^

Pour l'ex1, je bloque au *s2 = c, je ne me souviens plus comment on doit l'interprêter. Du coup, je bloque à tout en fait

S'il y a une âme charitable qui veut réaliser sa BA de la journée, toute aide est la bienvenue !

[poukill]

Code :

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

*s2 = c

ça fait appel au polymorphisme, qui est une des bases de tout langage orienté objet.
Ça veut dire que tu considère ton objet s2 (qui est un Circle normalement) comme un Shape.
L'affichage donne :

1
2
1

Alors que si on met le mot clé virtual dans Shape (encore une notion de base), le polymorphisme peut librement s'exprimer... (ce que suggère la question 2 )

[koala01]

Salut,

En complément, on peut insister sur le fait que, en Java, toutes les méthodes sont d'office virtuelles.

Ainsi, en java, il te suffit de redéfinir une méthode héritée de la classe de base pour que ce soit d'office ce nouveau comportement qui soit pris en compte dans le cadre du polymorphisme.

en C++, ce n'est pas le cas.

Si tu n'indique pas explicitement que ta méthode est virtuelle, elle ne l'est pas.

Cela implique que si tu redéfini une méthode héritée de la classe de base, mais que tu n'indiques pas qu'elle est virtuelle dans la classe de base, et que tu demande au compilateur de considérer une variable d'un type dérivé comme s'il s'agissait d'un type de base, ce sera bel et bien le comportement du type de base qui sera appliqué.

Au final, il est nécessaire de déclarer toutes les méthodes qui sont susceptibles d'être redéfinies dans un but de polymorphisme comme étant virtuelles en C++.

Bien qu'une méthode déclarée au départ comme virtuelle le reste dans les classes dérivées, il est également souhaitable (histoire de permettre au lecteur du code de s'en rappeler) de rappeler le mot clé virtual dans les classes dérivées qui fournissent un comportement adapté au type réel.

Par contre, il est déconseillé de déclarer une méthode qui ne devra jamais être réimplémentée comme étant virtuelle, car les mécanismes que cela implique au niveau de l'exécutable (création d'une VTable et déréférencement supplémentaire entre autres) ont malgré tout un cout au niveau des performances générales (que ce soit en temps d'exécution ou en taille de l'exécutable) même si le cout peut être considéré comme infime dans de nombreux cas.

De plus, le fait de déclarer une méthode comme étant virtuelle peut induire dans le chef du lecteur du code l'idée fausse que la méthode en question est susceptible d'être réimplémentée

[poukill]

Oui effectivement bien vu Koala. J'aurai du expliquer un peu mieux.
Celà dit, il m'est déjà arriver de mettre des virtual à des fonctions qui ne devaient pas en avoir juste à cause de l'utilisation d'un Proxy par la suite.

[zais_ethael]

1.1 : comme dit poukill
1.2 : il faut mettre un virtual à la méthode draw. De par le fait qu'on utilise du polymorphisme il serait aussi une très bonne idée de déclarer un destructeur virtuel dans la classe de base (petit rappel sur certains compilateurs comme gcc qui ont la bonne idée d'afficher un warning si on déclare une méthode virtuelle dans une classe dénuée de destructeur virtuel - ce n'est pas standard mais ça aide bien des développeurs qui l'oublient ou tout simplement ne savent pas que c'est nécessaire dans la plupart des cas)
1.3 : l'affichage devient alors ce qu'on aurait attendu dans un langage full-object: 1 2 2