1

Edited_995

2

pour apperler ton "OnEnterBackground" de "Player", il faut que ton pointeur d'objet "pApp" pointe sur un objet de type "Player" :

l'exemple suivant ne fonctionne pas car "pApp" n'est pas initialisé (c'est un pointeur fou) int main() { AppBase *pApp; pApp->OnEnterBackground(); return 0; }

Exemples qui fonctionnent : (sans le template pour le test) #include <stdio.h> class AppBase { public: virtual void OnEnterBackground() { printf("methode de AppBase\n"); } }; class App : public AppBase { public: virtual void OnEnterBackground() { printf("methode de App\n"); } }; class Player : public App { public: virtual void OnEnterBackground(void); }; void Player::OnEnterBackground() { printf("DidEnterBackground\n"); } int main() { // appel la methode de AppBase AppBase *pAppBase = new AppBase(); pAppBase->OnEnterBackground(); delete pAppBase; // appel la methode de App AppBase *pApp = new App(); pApp->OnEnterBackground(); delete pApp; // appel la methode de Player AppBase *pPlayer = new Player(); pPlayer->OnEnterBackground(); delete pPlayer; return 0; }

Il faut donc que tu récupères soit une référence, soit un pointeur sur ton objet instancié quelque part en mémoire.

Tu dois avoir un moyen pour récuperer cet objet généralement soit par un parametre à ta méthode, soit en utilisant un getter sur une classe associé voir à partir d'une classe singleton.

avatar

3

Il faudrait voir la façon dont AppBase *pApp; est initialisé si possible ?
En note : il n'y a pas de cheminement, une seule fonction sera appelée.

Je suis quand même surpris que la fonction virtuelle dans le template passe à la compilation.

4

Edited_996

5

Ya pas un problème de conception quand on doit appeler une méthode d'une classe dérivée² dans une classe grand-mère ?
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

6

Quand tu es obligé d'y faire appel via un cast sauvage de la part du codeur, si, c'est souvent mauvais signe.
Mais là, la méthode OnEnterBackground est déclarée dès la classe mère (qui d'ailleurs est une classe virtuelle pure, ie dont au moins une méthode doit être définie dans une classe dérivée.)<=edit, dsl elle n'est pas virtuelle pure, j'avais lu trop vite

7

Par exemple, tu te retrouverais avec

class A
{
}


class B extends A
{
   void huhu()
   {
   }
}


A* getAInstance()
{
   return new B ;//tu peux retourner un B* puisque B dérive de A, c'est pas un problème
}



main()
{
   static_cast<B*>(getAInstance())->huhu() ; //ça fonctionne mais c'est n'imp %)
}

8

Vu. En fait, dans le cas d'Orion, il a juste cherché à compléter sa classe mère, non ?
avatar
<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

9

Oué, si j'ai bien compris il a ajouté OnEnterBackground (qui n'est pas virtuelle pure, dsl j'ai mal lu, elle est simplement "virtual") dès la classe mère, et l'a ajoutée au passage aux classes filles (ce qui n'était pas utile s'il ne la redéfinit pas, d'ailleurs : son ajout dans App est superflu dans son exemple)

10

spectras (./3) :
Je suis quand même surpris que la fonction virtuelle dans le template passe à la compilation.

pourquoi ? trifus
Ya pas un problème de conception quand on doit appeler une méthode d'une classe dérivée² dans une classe grand-mère ?

pourquoi? hum c'est tout l'interet des virtual.. avoir une classe "grand-mere" qui est une interface abstraite, et la specialiser en heritant (potentiellement plusieurs fois)
apres, on peut ne pas aimer les arbres d'heritage tres profonds, mais c'est un autre debat...
avatar
HURRRR !

11

bearbecue (./10) :
pourquoi ? trifus.gif
Parce que je sais que le contraire ne fonctionne pas (impossible de déterminer la taille de la vtable), et que ne m'étant jamais posé la question avant dans ce sens là ça m'a surpris.
J'imagine qu'en creusant un peu ça doit être logique, mais être sûr de l'initialisation avant de creuser ça me semblait plus important. happy

12

bah, si confus
tous les types sont forcement connus au moment de la compil, ya qu'un seul layout possible de vtable oui t'herite jamais d'une template non-specialisee, sinon ca veut dire que t'instantie jamais ta classe.
avatar
HURRRR !

13

C'est à ça que je pensais : class A { template <class T> virtual void foo(T & x) {.......} }; Au moment de la compilation tu ne peux pas savoir combien tu vas en avoir, puisqu'il peut y en avoir d'autres dans d'autres sources, et tu vas être sacrément emmerdé au moment de linker. J'imagine qu'on pourrait résoudre partiellement la question en traquant les références dans la vtable pour les corriger au linkage, mais ça serait furieusement compliqué.

14

ah vi, avec les methodes templates, pas les classes templates.
parceque bon pour le coup sur les classes ouai la question se pose pas smile

meme au link ca serait chiant en fait...
enfin ptet si t'autorise ca que sur les symboles qui sont pas dllexport, mais c'est encore plus bordelique du coup...
avatar
HURRRR !

15

La règle telle que je me la formule, c'est qu'une méthode virtuelle ne peut pas être "plus template que sa classe". Ce qui n'est pas le cas ici.
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.