Discussion :

[twixnoir]

Bonjour !

Faisons court, faisons simple : J'aurais voulu faire quelque chose comme ceci :

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
// partie API
 
class A {
};
class B : public A {
      public:
            void doFunc () { cout << "bla" << endl; }
};
 
// partie Programmeur
 
void func (A& var) {
      var.doFunc();
}
 
int main () {
      /* ici pour test, en fait func est appelée par la partie API via un pointeur de fonction. */
      B var;
      func(var);
}

Pour que ce code compile je pourrais écrire le prototype de doFunc en virtual dans A. Mais ça, je ne le peux pas. En effet mes contraintes sont les suivantes:
- La classe de base A ne peut pas connaître le contenu des classes filles comme B.
- la signature de la fonction func doit être unique.

Un reinterpret_cast<B&>(e) est possible mais ce serait plutôt mal pratique à mon goût (puisque dans la partie Programmeur), je voudrais que la conversion soit transparente à l'utilisateur.

Et je travaille en C++2011

Je trouve dommage que le polymorphisme se limite aux méthodes qui sont déclarées dans le parent, à vrai dire je trouve ça tellement limité que je me demande s'il y a anguille sous roche ?

Merci

[Flob90]

Comment ton code doit se comporter si l'objet passé en paramètre est en réalité un A et pas un B ? A l'heure actuelle il y a un gros porblème car la fonction doFunc n'existe pas pour un A.

Le but du polymorphisme c'est d'avoir des comportements différents entre les différents objets d'une même hiérarchie, il faut néanmoins que tous les objets puissent recevoir le message, sinon ca n'a pas de sens.

[koala01]

Salut,

J'ai l'impression que tu te mérpends sur le sens qu'il faut donner à la virtualité des fonctions.

Lorsque l'on décide de rendre une fonction virtuelle, on envoie à l'utilisateur un message du genre de:

Je sais que la classe que je vous présente risque d'être dérivée.

Je ne peux déterminer que le comportement qui sera intéressant pour la classe mère

Vous pouvez donc décider d'adapter ce comportement, si vous considérez qu'il ne correspond pas à vos besoins pour les classes dérivées

Cela te permet donc, justement, d'autoriser l'appel de la fonction pour n'importe quel type "passant pour être" du type de la classe mère (comprends: pour n'importe quel type dérivé publiquement de la classe mère ) en assurant un comportement adapté à la classe mère, et sans qu'il ne faille prendre en compte les éventuelles classes dérivées (qui adapteront le comportement de la fonctions à leur propre réalité en cas de besoin)

[3DArchi]

Bonjour,

Je trouve dommage que le polymorphisme se limite aux méthodes qui sont déclarées dans le parent, à vrai dire je trouve ça tellement limité que je me demande s'il y a anguille sous roche ?

Le C++ a fait le choix d'avoir les fonctions virtuelles dans la classe et pas en dehors. (c'est au passage le choix partagé avec d'autres langages). Mais c'est peu lié à ton problème. Car, comme le souligne Flob90, pour que ton expression soit polymorphe (F.A.Q. : Qu'est ce que le polymorphisme), elle doit rester valide que l'objet soit de type B ou de type A. Sinon, elle ne l'est plus.

Peut être n'as-tu pas besoin d'un polymorphisme d'inclusion.

Difficile de donner une piste si on ne connait pas le besoin derrière. Cela donne plutôt l'impression que la solution vers laquelle tu t'orientes est trop tarabiscotée par rapport au problème à résoudre. Il existe certainement une solution ... encore faudrait-il connaître le problème...

[JolyLoic]

Je suis d'accord avec 3DArchi : Tu n'expose pas ton problème, mais une partie de solution qui ne marche pas. Ça ne nous donne pas assez d'information pour te proposer une alternative viable.

3DArchi semble suggèrer une solution à base de template et de duck-typing. Une solution dans une voie totalement opposée serait que A contienne une map<string, "pointeur de fonction qui va bien">, remplie dans le constructeur de B, et que l'on résolve tout dynamiquement à l'exécution.

[screetch]

Peut etre le problème est que A ne sait pas faire un doFunc mais que B sait le faire.
Mais même si A ne sait pas le faire, il est possible de dire au compilateur que toutes les sous-classes de A peuvent faire doFunc en declarant une fonction virtuelle pure.