Discussion :

[Aspic]

Si tu as un paramètre de plus dans la signature de ta fonction, ce sera considéré comme de la surcharge, et les deux « versions » seront considérées comme deux fonctions différentes, sauf si tu mets d'emblée tous les paramètres mais que tu précises une valeur par défaut pour le dernier, ce qui le rend optionnel.

Je n'arrive pas à surcharger ma fonction, le compilateur rale :

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
 
// dans la classe mère => CAS 1
virtual void attaquer(int x, int y);
virtual void attaquer();
 
// ou alors ca  => CAS 2
virtual void attaquer(int x, int y)=0;
virtual void attaquer()=0;
 
 
// dans la classe fille guerrier, j'ai définie que :
void attaquer()
{
}
 
// dans la classe fille magicien, j'ai défini que :
virtual void attaquer(int x, int y)
{
}

Dans le CAS 1, erreur :

cannot allocate an object of type `t_guerrier'
because the following virtual functions are abstract:
virtual void t_ennemie::attaquer(int, int)

// et d'autres erreurs du même type

Dans le CAS 2, erreur :

undefined reference to `t_ennemie::attaquer(int, int)

// et d'autres erreurs du même type

Y'a un truc que j'ai pas compris ?

[Obsidian]

À mon avis, tu as inversé les cas 1 et 2 quelque part dans ton exemple.

Lorsque tu ajoutes « =0 » à la fin de la déclaration d'une méthode virtuelle, c'est pour en faire une méthode « virtuelle pure », c'est-à-dire une méthode qui a le droit de ne pas exister dans ta classe, et qui ne sera définie que dans une de ses descendantes (sous-classe, sous-sous-classe, …).*Évidemment, si c'est le cas, ta classe pourra être dérivée, mais ne pourra pas être instanciée : aucun objet de ta classe ne peut être créé car elle déclare une fonction membre que tu ne peux pas utiliser.

Dans le second cas, tes fonctions membres ne sont pas virtuelles « pures », donc elles doivent être définies pour la classe à laquelle elles correspondent. Si elles ne le sont pas, le compilo va se plaindre car tu y fais référence mais, à l'édition des liens, il ne les trouve pas.

[Aspic]

Pour le =0, je savait que c'était une méthode virtuelle pure et qu'on devait obligatoirement les déclarer dans toutes les classes filles et pas dans la classe mère.

Dans le second cas, tes fonctions membres ne sont pas virtuelles « pures », donc elles doivent être définies pour la classe à laquelle elles correspondent. Si elles ne le sont pas, le compilo va se plaindre car tu y fais référence mais, à l'édition des liens, il ne les trouve pas.

Ok mais ca ne marche toujours pas quand je les déclare dans la classe mère...

J'ai une erreur vraiment tordu :

In function
`_ZN9__gnu_cxxmiIPP9t_ennemieS3_St6vectorIS2_SaIS2_EEEENS_17__
normal_iteratorIT_T1_E15difference_typeERKSA_RKNS7_IT0_S9_EE':
undefined reference to `t_ennemie::attaquer(int, int)
undefined reference to `t_ennemie::attaquer()

Code complet :

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
21
22
23
24
25
26
27
28
29
30
31
 
class t_ennemie
{
public:
// constructeurs destructeurs...
 
virtual void attaquer() {};
virtual void attaquer(int x, int y) {};
};
 
 
class guerrier: public t_ennemie
{
public:
// constructeurs destructeurs...
 
void attaquer() {
// du code
}
};
 
 
class magicien: public t_ennemie
{
public:
// constructeurs destructeurs...
 
void attaquer(int x, int y) {
// du code
}
};

[Obsidian]

Pour le =0, je savait que c'était une méthode virtuelle pure et qu'on devait obligatoirement les déclarer dans toutes les classes filles et pas dans la classe mère.

Ok mais ca ne marche toujours pas quand je les déclare dans la classe mère...

Si elles sont virtuelles ordinaires (ou même pas virtuelles du tout), il ne faut pas seulement les déclarer, il faut aussi les définir.

J'ai une erreur vraiment tordu :

Ce n'est pas une erreur tordue, c'est un message du linker. Les symboles bizarres que tu vois correspondent à des noms de fichiers temporaires et aux décorations des noms de fonctions.

C'est ce que je disais au-dessus : tu annonces l'existence de fonctions (membres ou pas). Soit. Le compilateur te croit sur parole jusqu'à la construction de l'exécutable où ces fameuses fonctions restent introuvables.

Par contre, dans ton dernier exemple, tu as ajouté les accolades après les noms de tes fonctions-membres, ce qui en fait des fonctions inline, et devrait leur permettre de compiler.

Tu utilises quelle version de ton compilateur ?

[Aspic]

Tiens c'est marrant ca marche quand on les mets en fonction inline dans le .h mais quand je les définies dans le .cpp avec des accolades vides, ca ne compile pas

Je reviens sur mon problème car je me suis mal exprimé c'est de ma faute, voilà mon code du main :

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
int main()
{
     t_guerrier* guerrier1 = new t_guerrier(...);
     t_magicien* magicien1= new t_magicien(...);
     vector<t_ennemie*> tab;
     tab.push_back(guerrier1);
     tab.push_back(magicien1);
     int paramMagicien, int paramMagGuerrier;
 
     // parcourt des items
     for(.....)
     {
           // que mettre la sachant que le magicien pour attaquer à besoin de 2 arguments alors que le guerrier un seul...  
           //tab[i]->attaquer();
           // ou alors tab[i]->attaquer(paramMagGuerrier, paramMagicien);
     }
}

Les classes :

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
21
22
23
24
25
26
27
28
29
30
 
class t_ennemie
{
public:
// constructeurs destructeurs...
 
virtual void attaquer(int x) {};
virtual void attaquer(int x, int y) {};
};
 
class t_guerrier: public t_ennemie
{
public:
// constructeurs destructeurs...
 
void attaquer(int x) {
// du code
}
};
 
 
class t_magicien: public t_ennemie
{
public:
// constructeurs destructeurs...
 
void attaquer(int x, int y) {
// du code
}
};

Le problème c'est que à cause du vector, je pers l'info sur la vrai type de l'objet donc quand je le récupère, je ne sais pas si c'est un magicien ou un guerrier, c'est pour ca que je passe par le polymorphisme. Mais dans le cas où les fonctions n'ont pas le même nombre de paramètre, comment fais t-on ?

Peut être existe t-il un autre structure type tableau permettant de garder l'info du type de l'objet et pas trop galère à gérer niveau mémoire ? (j'ai rien trouvé dans la STL) ?

Merci

[Joel F]

Travaille ton interface pour que ca rentre, genre avec des tuple etc...
On ne demande jamais le type concret d'un type abstrait, c'est impoli.

[dragonjoker59]

Sinon, tu peux toujours faire un test grâce à typeid :

Code :

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

1
2
3
4
5
6
7
8
9
 
if (typeid( * tab[i]) == typeid( t_magicien))
{
	//c'est un magicien
}
else if (typeid( * tab[i]) == typeid( t_guerrier))
{
	//c'est un guerrier
}

Cependant je pense que la méthode des tuples est la meilleure, tu peux aussi te renseigner sur les va_list qui te permettent aussi un nombre d'arguments variable tant qu'il y en a au moins 1.

[Astraya]

Et c'est là qu'intervient la splendide philosophie du "préféré association à héritage"! Si tu n'es pas trop avancé dans ton projet, regarde du coté du GOC

[Obsidian]

Tiens c'est marrant ca marche quand on les mets en fonction inline dans le .h mais quand je les définies dans le .cpp avec des accolades vides, ca ne compile pas

Oui, mais ça devrait quand même. S'il ne les a pas trouvées, c'est que tu ne les as pas définies correctement. Tu peux nous montrer ton code *.cpp ? Définir ces fonctions inline est une mauvaise idée, également.

[Astraya]

C'est peut-être bête ce que je vais dire mais je ne vois pas plus sur le code pour trouver mieux.
Pourquoi ne pas mettre une seule fonction attaquer() virtuel, avec un seul paramètre type Position.

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
//class position
class Position
{
    int x,y;
}
 
//class t_ennemie
class t_ennemie
{
    virtual void attaquer(Position *p) = 0;
};
 
//class guerrier
class guerrier : public t_ennemie
{
     void attaquerCorpsACorps()
     {
       //Jacky chan
     }
     void attaquer(Position *p = 0)
     {
       attaquerCorpsACorps();
     }
};
 
//class magicien
class magicien : public t_ennemie
{
     void attaquerADistance()
     {
        //feu!!
     }
     void attaquer(Position * p)
     {
        attaquerADistance();
     }
};

Edit ( philosophie et réflexion):
D'ailleurs, ne serais-t-il pas plus sage de voir les guerriers et les magiciens comme des personnes humaines avant de les voir comme des ennemis? Pour la complexité du code?
D'ailleurs, qu'est ce qui différencie un ennemi d'un gentil? un camp? un gang? cela voudrais dire que la personne humaine appartient à un camp ou gang (ennemi ou allié) et que cette personne connaissent son gang ou camp ( agrégation? )

[Joel F]

tu peux aussi te renseigner sur les va_list qui te permettent aussi un nombre d'arguments variable tant qu'il y en a au moins 1.

comme les va_list ne gérent pas les objets, elles sont à éviter en C++

[Aspic]

Oui, mais ça devrait quand même. S'il ne les a pas trouvées, c'est que tu ne les as pas définies correctement. Tu peux nous montrer ton code *.cpp ? Définir ces fonctions inline est une mauvaise idée, également.

Voilà le code :

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
 
#include "t_ennemie.h"
 
// constructeurs et destructeur virtuel
 
void attaquer(int x)
{
}
 
void attaquer(int x, int y)
{
 
}
 
// plein d'autres fonctions

Sinon j'ai pris au pif la classe magicien et guerrier pour simplifier dans ce topic mais dans mon jeu y'a ps de magicien ni guerrier ^^ lol

Ce sont tous des ennemies mais ils sont de différents type et ont des attaques spéciales ou des comportements différents à l'affichage d'où le polymorphisme.

Pour l'instant j'ai contourné le problème en rajoutant les deux attribues dont j'avais besoin dans la classe mère en protected comme ca les classes filles qui en ont besoin y ont accès et ca marche mais bon je pense pas que ce soit du "code propre".

De plus, est ce que l'utilisation du type_id() est à proscrire en C++ ? car ca résoudrait mon problème ^^

[Obsidian]

Hello,

Voilà le code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include "t_ennemie.h"
 
// constructeurs et destructeur virtuel
 
void attaquer(int x)
{
}
 
void attaquer(int x, int y)
{
 
}

Ça, ce ne sont pas des fonctions-membres mais des fonctions ordinaires, définies au sommet du namespace et en dehors de toute classe. Il faut les préfixer :

Code :

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

1
2
3
4
5
6
7
8
9
 
void t_ennemie::attaquer(int x)
{
}
 
void t_ennemie::attaquer(int x, int y)
{
 
}

Pour type_id(), toutes ces notions font en fait partie du RTTI. Ce n'est pas interdit, mais c'est déconseillé, justement pour éviter de se retrouver dans la situation qui nous occupe en ce moment.

[Astraya]

Pour l'instant j'ai contourné le problème en rajoutant les deux attribues dont j'avais besoin dans la classe mère en protected comme ca les classes filles qui en ont besoin y ont accès et ca marche mais bon je pense pas que ce soit du "code propre".

Lorsque l'on ne sais pas ou mettre des variables, dans la classe mère ou dans la classe fille. Les encapsuler, ce donner une meilleur visibilité est souvent une approche fort utile

x et y sont des positions, pourquoi ne pas l'encapsuler? Cela ne ralentira pas ton jeu!

[Aspic]

Hello,
Ça, ce ne sont pas des fonctions-membres mais des fonctions ordinaires, définies au sommet du namespace et en dehors de toute classe. Il faut les préfixer :

Je suis vraiment un boulet, en plus je le savais mai à 1h du mat ce matin, j'avais l'esprit un peu ailleurs ^^

@Astraya :
Sinon quand tu parles d'encapsuler la position, tu veux dire la mettre comme attribue dans la classe mère comme j'ai fais ? Donc au finale, mon idée ne serait pas une trop mauvaise solution ?

[Astraya]

Sinon quand tu parles d'encapsuler la position, tu veux dire la mettre comme attribue dans la classe mère comme j'ai fais ? Donc au finale, mon idée ne serait pas une trop mauvaise solution ?

Et bien tout dépend à quoi servent les coordonnées; est-ce la position du joueur? l'endroit de l'attaque (avec zelda l'endroit de l'attaque est la position du joueur)?

Lors de l'attaque, tu cliques sur un monstre ou tu le fais attaquer en fonction de l'arme face à lui sans ce soucier du reste?

Ceci est un plus un problème d'architecture que de code

[Aspic]

En fait il s'agit des coordonnées de Link.
Un certain type d'ennemie appelé "ver de sable" doit connaitre la position de Link à tout moment pour le poursuivre ^^ alors que les ennemies de base n'ont pas à avoir accès à cette info car il bouge aléatoirement.

Vu que je n'arrivais pas à faire cela, j'ai mis posLinkX et posLinkY dans la classe mère t_ennemie en protected comme ca tout le monde y a accès c'est pas exactement ce que je voulais faire mais ca passe...

[Astraya]

Un certain type d'ennemie appelé "ver de sable" doit connaitre la position de Link à tout moment pour le poursuivre

Si il le poursuit pourquoi appeler cette méthode attaquer?
Attaquer serais plus l'action d'attaquer une cible, poursuivre l'action de poursuivre. tu n'attaques pas tant que la poursuite n'est pas fini.
Mais dans ce cas, passer une référence sur la position réel de Link mise à jour à chaque frame, serais une bonne piste et ton pathfinding ce charge du reste normalement

[Aspic]

La fonction s'appelle bouger() et pas attaquer car dans les zelda, les ennemies n'attaque pas avec des armes (sauf ennemies spéciaux qui lance des trucs mais j'en suis pas là)

Mais dans ce cas, passer une référence sur la position réel de Link mise à jour à chaque frame, serais une bonne piste et ton pathfinding ce charge du reste normalement

Ca a l'air intéresant mais comment faire ca ?

[Astraya]

Et bien :

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
21
 
class Hero{
    Position pos;
}
class Link: public Hero
{
    void Deplacer(Position &nouvellePosition)
    {
        pos = nouvellePosition;
    }
};
 
class guerrier
{
    Position pos;
 
    void Attaquer(Hero &h)
    {
         pathfinding(pos, h.pos); //pas forcement tout les frames mais bon pour que ça sois plus simple.
    }
};

J'ai rajouté ici la classe Heros au cas ou tu aurais envie de faire d'autres heros que Link, sinon tu peux mettre la position directement dans link et passer à la fonction attaquer(Link &l).

Ce qui va ce passer:
- mise à jour de la position de link
- Le guerrier connait tout le temps la position de link ( pour ne pas le faire attaquer tout le temps, cette fonction devrais probablement être précédé d'un test de visibilité de la créature )
- Le guerrier a une référence sur la position de link, aucune copie, un accès sans indirection ( pas de pointeur ), une mise à jour "automatique" à chaque frame.