quelle est la portée de la surcharge ?

Version imprimable

Bonjour,

effectivement, je me pose la question de connaitre la portée de la surcharge. De par mon expérience, j'ai l'impression que la surcharge de fonctions (des fonctions portant le même nom mais ayant des signatures différentes) ne peut se faire qu'au sein d'une même classe et pas au sein de deux classes ayant une relation mère/fille.

Le cas concret qui me pose problème et où j'aimerai bien que la portée soit "héréditaire" en quelque sorte, est le suivant:
Je défini une fonction template dans une classe mère, utilisée par plusieurs classes filles, avec des types spécifiques. Chacune de ces classes filles utilisent la fonction template, qui fait appel à des fonctions spécialisées, ayant des paramètres différents, mais portant le même nom; d'où la notion de surcharge. Mais, cela ne fonctionne pas.

Concrètement :

Soit une classe "AbstractClient", classe mère qui implémente la fonction template.
Une autre classe, gère une collection de classes filles de AbstractClient sous forme de pointeur AbstractClient*, et appelle les fonctions virtuelles "processFrame" avec des objets de classes filles de Frame, sous la forme de Frame* :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class AbstractClient { template < typename FrameSpe > void checkFrame( Frame* pFrame) { FrameSpe* pFrameSpe = dynamic_cast<FrameSpe*>(pFrame); if ( pFrameSpe ) processFrame( pFrameSpe ); } virtual void processFrame( Frame* ) { TRACE("Ce type de Frame n'est pas géré ! "); } };
et une des classe fille de AbstractClient :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 class ConcreteClient { void processFrame( Frame* pFrame ) { checkFrame<FrameToto>(pFrame); checkFrame<FrameTata>(pFrame); checkFrame<FrameTiti>(pFrame); } // fonction qui traite les FrameToto void processFrame( FrameToto* pFrame) { // faire quelque chose avec des FrameToto } // fonction qui traite les FrameTata void processFrame( FrameTata* pFrame) { // faire quelque chose avec des FrameTata } };
Cette structure de classes me permettrait de gérer un grand nombre de classes héritant de Frame (j'en ai 46 dans le monde concret, selon un arbre d'héritage de à 3 niveaux), et un nombre de classes clientes variables (au moins une vingtaine), héritant de "AbstractClient".

Mais ce code ne marche pas, tel quel : les fonctions "spécialisées pour les sous-types de Frame" ne sont jamais appelées.
Par contre, si je mets la fonction template dans ConcreteClient, la ça fonctionne.
D'où mon impression de départ : "la portée de la surcharge de fonction semble n'être possible qu'au sein d'une même classe, et ne peut s'hériter".
Et c'est bien dommage !
Je ne sais pas si j'ai été très clair. L'avis des experts m'intérresse...

La seule solution que je vois est de ne pas utiliser de fonction template, mais de coder le "dynamic_cast" dans chaque processFrame(Frame*) des classes héritant de AbstractClient.

salut,

:D hmm tout n'est pas clair dans ma tête. Et le fait que la classe mère est une méthode checkFrame qui fait appelle à processFrame et que la classe fille est des méthodes processFrame appelant checkFrame me perturbe un peu.

Si je ne suis pas trop à côté de la plaque, ce que tu essaies d'appliquer c'est le pattern "Patron de méthodes" (cf. template method).

Pour résumé, la classe mère abstraite définit une méthode patronMethode() appelant une ou plusieurs méthodes primitiveX() virtuelles pures (et généralement privées). A la charge des classes filles d'implémenter les méthodes primitivesX().
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 classe mere { public: void patronMethode() { ... primitive1(); ... } ... protected: void primitive1() = 0; }; classe fille1 : public mere { ... private: void primitive1() { // implémentation fille1 } }; classe fille2 : public mere { ... private: void primitive1() { // implémentation fille2 } };
Code:

1 2 3 4 5 fille1 f1; fille2 f2; f1.patronMethode(); f2.patronMethode();
A adapter à ton cas.

22/08/2005, 01h58
Luc Hermitte

La surcharge dans une hiérarchie se traduit par un masquage.
=> using devrait être ton ami -- je ne l'ai jamais essayé avec des templates au milieu.

juste un idee

Code:

1
2
3
4
5
6
7
 
void processFrame( Frame* pFrame ) 
{ 
AbstractClient ::checkFrame<FrameToto>(pFrame); 
AbstractClient ::checkFrame<FrameTata>(pFrame); 
AbstractClient ::checkFrame<FrameTiti>(pFrame); 
}

22/08/2005, 19h46
tut

bigboomshakala : sur le principe, c'est ça, à part qu'il faut y ajouter des signatures différentes pour les fonctions (pour les spécialiser dans le traitement de classes spécialisées), le tout saupoudrer de template...

Luc Hermitte : 'La surcharge dans une hiérarchie se traduit par un masquage', qu'est-ce que tu veux dire par là ? je vais essayer de me pencher sur le "using" directive...

lepoutho : merci de ta proposition, mais mon problème apparaît dans l'autre sens : il monte de ConcretClient vers AbstractClient, c'est à la descente que ça foire...

Mais je ne vais pas non plus implémenter une usine à gaz, parce que le principe c'est justement de simplifier le bazar et d'avoir des ConcretClient qui puissent dire dans leur processFrame(Frame*) générique :
"alors moi, ce qui m'interresse c'est les FrameToto, FrameTata, FrameTiti, le reste je m'en cogne".
et puis charge à elles d'implémenter les fonctions spécialisées de traitement : processFrame( FrameToto*), processFrame(FrameTata*), processFrame(FrameTiti*),

Au pire, j'implémente mon template par une macro, et le tour est joué, mais, quelque part ça me chiffonne d'utiliser les macros.
Point de vue personnelle, pas de polémique.

Merci pour votre aide en tout cas !
:D
22/08/2005, 20h31
Luc Hermitte

Ca veut dire que par défaut (sans using), dans les enfants on ne surcharge (ajout) pas, mais on masque (RAZ puis ajout).
23/08/2005, 17h04
bountykiller

Moi, j'ai l'impression que les choses se passent de la façon suivante:
dans ta fonction template, tu appelles processFrame sur un descendant de Frame*. La seule fonction trouvée qui correspond est celle de la classe
AbstractClient. Comme celle-ci est virtuelle, le programme recherche une fonction processFrame ayant la même signature dans la classe fille et n'appelle donc pas les surcharges de ta fonction.
Si tu mets la fonction template dans les classes filles, celle-ci trouvent automatiquement la bonne fonction, et donc pas de prob.
Ma solution (a tester): changer l'appel à processFrame dans la fonction template en this->processFrame. De cette façon, l'appel prendra en compte les surcharges présentes dans la classe fille.

Citation:

Envoyé par Luc Hermitte

Ca veut dire que par défaut (sans using), dans les enfants on ne surcharge (ajout) pas, mais on masque (RAZ puis ajout).

Tu peux en dire un peu plus ou donner un lien STP? Merci.
23/08/2005, 20h33
Luc Hermitte

Il est difficile d'en dire plus. C'est comme ça.
Quand tu crois surcharger une fonction issue d'une classe dont tu hérites, en fait tu ne surcharges pas, mais tu masques la fonction qui devient alors indisponible directement.

C'est tout c'est comme ça. Ce devrait être traité dans n'importe quel bouquin/cours a priori.
23/08/2005, 21h30
bountykiller

Citation:

Envoyé par Luc Hermitte

Il est difficile d'en dire plus. C'est comme ça.
Quand tu crois surcharger une fonction issue d'une classe dont tu hérites, en fait tu ne surcharges pas, mais tu masques la fonction qui devient alors indisponible directement.

C'est tout c'est comme ça. Ce devrait être traité dans n'importe quel bouquin/cours a priori.

Bon, d'accord, mais quand même.. Pourquoi son code ne fonctionne-t-il pas alors? Et qu'est ce que le using a à voir là dedans (un exemple serait le bienvenu).
J'ai regardé dans différents cours sur le net, j'ai rien trouvé là dessus.

Code:

1 2 3 4 5 6 7 8 9 10 struct A { void f(float); }; struct B : A{ void f(int); }; ... B b; b.f(12.42); // pas content!!
B::f(int) masque A::f(float);
Code:

1 2 3 4 5 6 7 8 9 10 11 struct A { void f(float); }; struct B : A{ using A::f; void f(int); }; ... B b; b.f(12.42); // content!!
On réimporte A::f(float) dans B.

Et son code me semble assez correspondre à se cas de figure.

je n'ai pas réussi à utiliser le "using", à chaque fois le compilo n'était pas content...
Du coup, j'ai réussi à modifier mon template, pour que ça marche, en servant de l'opérateur de résolution de portée.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
AbstractClient
{
   template < typename ClientToCall, typename FrameSpe > void checkFrame( Frame* pFrame) 
   { 
      if ( FrameSpe* pFrameSpe = dynamic_cast<FrameSpe*>(pFrame) )
      {
         if ( ClientToCall* pClient = dynamic_cast<ClientToCall*>(this) )
         {
            pClient->processFrame( pFrameSpe );
         }
      }
   } 
};

et donc le ConcretClient :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
class ConcreteClient 
{ 
   void processFrame( Frame* pFrame ) 
   { 
      checkFrame<ConcreteClient, FrameToto>(pFrame); 
      checkFrame<ConcreteClient, FrameTata>(pFrame); 
      checkFrame<ConcreteClient, FrameTiti>(pFrame); 
   } 
 
   // fonction qui traite les FrameToto 
   void processFrame( FrameToto* pFrame) 
   { // faire quelque chose avec des FrameToto } 
 
   // fonction qui traite les FrameTata 
   void processFrame( FrameTata* pFrame) 
   { // faire quelque chose avec des FrameTata } 
 
};

Voila, ça marche !
Merci à tous.

24/08/2005, 14h53
bountykiller
Citation:
Envoyé par Luc Hermitte

Code:

1 2 3 4 5 6 7 8 9 10 struct A { void f(float); }; struct B : A{ void f(int); }; ... B b; b.f(12.42); // pas content!!

B::f(int) masque A::f(float);

Code:

1 2 3 4 5 6 7 8 9 10 11 struct A { void f(float); }; struct B : A{ using A::f; void f(int); }; ... B b; b.f(12.42); // content!!

On réimporte A::f(float) dans B.

Et son code me semble assez correspondre à se cas de figure.
A ok, je ne suis pas certain que cela corresponde quand même à son cas de figure (il a déjà surchargé son void processFrame( Frame* pFrame ) ) mais au moins j'ai appris quelque chose. Merci :wink: