Discussion :

[subzero01]

Bonjour,
j'ai une classe mere A qui est abstraite, et deux autres B et C qui heritent et definissent les methodes virtuelles de A.

j'ai un pointeur de type B et je veux en obtenir un pointeur de type C.
Je veux donc pouvoir appeler une des methodes virtuelles en tant que C (alors que j'ai un pointeur de type B).

j'espere avoir été assez clair.

PS: si je dois utiliser le dynamic_cast veuillez m'expliquer comment car j'ai tenté mais je recois un pointeur NULL (j'ai bien activé le RTTI dans VS).

merci à vous.

[bacelar]

B est une A.
C est une A.
Mais B n'est pas une C.

Il est donc normal de pas pouvoir appliquer les méthodes de la classe C sur une instance B, encore heureux.

Alors, si B doit être en spécialisation de C, B devrait dériver de C et non de A.
Cela règle tous les problèmes de cast, vu qu'ils ne servent à rien.

Si B n'est pas une C, si vous devez utilisez une méthode de C sur une instance B, c'est que, très vraisemblablement, la méthode ne devrait pas être une méthode d'instance de C.

Convertissez la méthode d'instance de C en méthode de classe ou en fonction libre qui prendra en paramètre une instance de B ou de A, en fonction de la sémantique du traitement.

Vous êtes sûr que ces fonctions ne seraient pas mieux comme méthodes de B ?

[subzero01]

appelons la methode virtuelle go(), chaque methode de chaque classe fille doit realiser un comportement different dans go(), mais il m'arrive a détecter que dans un cas (un bloc if) de la methode go() de la classe B on tombe sur le meme comportement de celui de go de la classe C, donc je me suis dit peut etre on peut considérer l'instance B comme etant une instance C et appeler la methode go().
voilà j'espere encore etre assez claire et merci

[bacelar]

considérer l'instance B comme etant une instance C

C'est oui -> B dérive de C et go de la classe B peut appeler C::go().

C'est faux ->
Si le code de ma méthode go de C peut indifféremment travailler sur une instance de B ou de C, elle peut, très vraisemblablement, travailler sur une instance de A.

Donc sémantiquement, C::go() est, peut-être, plus A::go() que C::go().
Si vous transférez C::go() vers A::go(), vous n'avez plus de problème car B::go() peut appeler A::go().

Si, pour des raisons de conception A::go() doit être virtuelle pure ou avoir une implémentation différente de l'actuelle C::go() ; vous pouvez toujours créer une méthode protected dans A, _go par exemple :

Code :

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

1
2
3
C::go(){return A::_go();};
 
B::go(){...if(...){A::_go();}...};

Il y a encore bien d’autres design patterns applicables en fonction de la vraie nature de A, B et C, mais n'essayez pas de mettre des ronds dans des carrés.

[subzero01]

tres jolie explication.
je vous remercie infiniment.
je laisse tomber le caste et je copie colle la partie qui concerne le traitement voulu, c'est plus propre pour moi )
a bientot

[bacelar]

Il n'y a que le mauvais code qui se copy-colle.

Si vous ne voulez pas vous prendre la tête, faites une fonction libre avec le code commun.

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
void gogo(A& a,...)
{
   a.titi = ...
}
 
 
C::go()
{
   gogo(this);
}
 
B::go()
{
...
   if(...)
   {
       gogo(this);
   }
...
}

[subzero01]

c'est un tres bon exemple je vais essayer d'en inspirer pour mon cas.
merci pour tout