Hop, rattrapéil y a des chances que ce soit moi
Si tu y vois plus clair c'est pas mal !alors voila un main() de 30 ligne environ c'est bon ou faut encore raccourcir ?
Après tu peux sans doute faire disparaitre encore la moitée de ton code !!
A chaque ligne et temps passé dessus, tu t'améliores, tu peux maintenant sans doute améliorer des choses que tu as faites au début.
C'est la fonction deplacejoueur() qu'il faut rétrécir à présent:
Déjà, ceci peut être mis dans une fonction de conversion à part. Et sans doute avec un switch plutôt qu'une suite de if.
PS: tidus.~Player();
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12 bool exit = false; TOUCHE touche; if(ch == KEY_UP) touche = haut; else if( ch == KEY_DOWN) touche == bas; else if( ch == KEY_RIGHT) touche = droite; else if( ch == KEY_LEFT) touche = gauche; else if( ch == 27) exit = true;![]()
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
par contre je pense que je vais avoir d'un ame charitable car la dans mon main j'ai les fonctions et ces fonctions je ne sais pas si je peut les mettre comme je veut donc si quelqu'un pourrai regarder les sources fourni dans ce post et me dire lesquels peuvent etre extrait du main en sécurité sa serais simpa
Parce qu'on ne détruit rien soit même.
Il suffit que la variable sorte de sa portée de définition pour que ce soit fait.
Non, c'est un problème de design, il faut pas compenser en faisant une technique tordue
FAQ - Est-il possible d'invoquer explicitement le destructeur d'une classe ?
A ta place je repartirais à zéro
!!! Tu ne perdras pas beaucoup de temps car tu as déjà digéré beaucoup de notions.
( le temps consacré à la compréhension est majoritaire ! )
Par contre tu en gagneras en clarté !
( Si tu modifies partie par partie, ça va être compliqué, là l’intérêt de tout séparer ! )
Tu dois faire plus de classes, et n'y intégrer QUE ce qui leurs servent, tu verras alors comment ton code peut ce décomposé.
( classes Memory, Keyboard, Display seront sans doute les principales ?! Avec ces trois tu peux encore bien diviser ton main )
Tu as tout planqué dans main.h, tes structures peuvent te servirent de base pour tes classes.
Si tu veux tuer un personnage, tu le retire de sa liste, le dépointe, le perd de scope, mais, ô grand jamais, tu ne le ~es pas.
Effectivement, recoder peut être une bonne solution.
Il te faut que chaque classe puisse présenter une interface atomique, de façon à ce que chaque fonction (non statique) d'une classe n'ai qu'un seul rôle.
par exemple: une créature, un joueur, un monstre, une case.
Un bon guide, si tu sens qu'une fonction doit aller dans une classe, mais que tu hésites sur laquelle, c'est probablement qu'il en manque une.
tout recoder sa fait mal surtout que je n'est pas trop une vision de certain truc (exemple les operateurs j'ai essayer de les incruster dans le position il les as refuser )
je vais essayer de voir si je ne peut pas bricoler un peu pour mettre mieux cela en forme dans premier temps
si je fais ces changement la
- un fichier SMap.h/.c
- un fichier Scoffres.h
- un fichier Smonstre.h
- les fonction de deplacement dans la class deplacement
- enum dans la class deplacement
- et voir si je peux caler les operator dans class position
aprés cela le main devrai etre sans fonction et avec 1 ou 2 include de SMap.h et Scoffres voir seulement Smap.h car Smap.h aura elle Scoffres et Smonstre.h inclu en elle
alors voila j'ai fait mes beau fichier et inclu mes code mais quand exemple je fait cela
il me dis
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 void move(Deplacement const & dep) { position_=Position(x()+dep.distanceX(), y()+dep.distanceY()); }
alors que j'ai bien fait
Code : Sélectionner tout - Visualiser dans une fenêtre à part C:\Users\kevin\Desktop\essai\joueur.h|20|error: 'Deplacement' has not been declared|
alors pourquoi avec lui il refuse tandis que avec
Code : Sélectionner tout - Visualiser dans une fenêtre à part #include "deplacement.h"
et
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 void tilecoffre(Joueur & joueur) { tiles[joueur.y()*cols + joueur.x()] = 'O'; }
il fonctionne trés bien.
Code : Sélectionner tout - Visualiser dans une fenêtre à part #include "joueur.h"
alors voila je suis presque a terme il me reste les operator donc la etant vraiment a la connaissance 0 de cela j'aurai aimer savoir comment les placé 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
22
23
24
25 #ifndef POSITION_H_INCLUDED #define POSITION_H_INCLUDED #include <cstring> class Position { public: Position(size_t x, size_t y):x_(x), y_(y){} // y = rows , x = cols //~Position(){} int x() const{return x_;} int y() const{return y_;} void changepos(size_t x, size_t y) { this->x_ = x; this->y_ = y; } //void setx(size_t x){this.x_ = x;} //void sety(size_t y){this.y_ = y;} private: size_t x_; size_t y_; }; #endif // POSITION_H_INCLUDED
bien sur j'ai essayer de les placé mais le compilo ma balancer des erreurs donc voila un peu d'aide sur sa serais vraiment bénéfique
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 bool operator <(Position const & first, Position const & second) { return first.x() < second.x() || (first.x() == second.x() && first.y() < second.y() ); } /* et, tant qu'à faire, te l'opérateur de comparaison == (pour d'autres * usages ultérieurs, très certainement ;) */ bool operator ==(Position const & first, Position const & second) { return ( first.x() == second.x() && first.y() == second.y() ); } bool operator !=(Position const & first, Position const & second) { return !(first == second); }
edit: bon bah finalement j'ai réussi a les placé l'erreur est que j'essayer de les placer dans les methode public alors que c'est une fonction a part
alors voila aprés quelque heures a tout demeler et corriger toute les erreurs je vous transmet une version un peu plus propre que la précédante
Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
Un peu de programmation réseau ?
Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.
J'ai l'impression que Bousk n'y met pas du sien![]()
Ca pourrait être intéressant de virer les fichiers texte qui ne sont pas utilisés, et de réorganiser tout ça (les fichiers de donnée dans un répertoire data, par exemple ; les fichiers h et cpp dans un répertoire src ; ...) histoire de simplifier la compréhension du total.
Et puis, tu n'as pas besoin de mettre le répertoire obj
Profite en pour virer tout le code commenté. Il n'est pas utile, ralonge les fichiers, et rend la lecture du tout plus complexe.
Maintenant, la critique du code :
* "using namespace std" ne doit jamais être utilisé (l'enlever permet de bien mettre en évidence l'utilisation de la librairie standard, vu que chaque utilisation est préfixée de std:: (5 caractères, c'est pas la mort)).
* main.h ? non, très mauvaise idée. Chaque .cpp doit inclure les headers dont il se sert, et ce de manière indépendante des headers qui sont inclus par le jeu des dépendances. Un court exemple :
Alors classe3.cpp doit include classe2.h, et ce même si ce fichier est automatiquement inclus du fait de l'inclusion de classe1.h. La raison derrière ce point : les dépendances peuvent changer au gré des refactoring. Un refactoring étant par essence local, il ne doit pas avoir d'impact global. Si classe1.h n'a plus besoin de classe2.h et ne l'inclus plus, alors classe3.cpp doit quand même compiler.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 // classe1.h include "classe2.h" ... // classe3.cpp #include "classe1.h" ... classe2 un_objet;
Bien évidemment, si classe3.cpp ne traite pas directement d'objets de type classe2, alors il n'inclus pas classe2.h (l'inclusion étant alors un détail d'implémentation de classe1.h).
En outre, le fait d'inclure dans un .cpp tous les headers dont il a besoin.
* il n'y a pas assez d'encapsulation dans ce code. En fait, il y a trop peu de classes - certaines fonctions mériterait d'être regroupées dans une classe (ne me demande pas lesquelles ; tu a fait le découpage en fichiers, donc tu sais grosso-modo ce qui peut être mis dans une classe, n'est-ce pas ?)
* certaines fonctions sont trop complexes. Des outils comme SourceMonitor (http://www.campwoodsw.com/) peuvent identifier les fonctions qui sont trop complexes (en utilisant une métrique connue sous le nom de "complexité cyclomatique de McCabe" (http://en.wikipedia.org/wiki/Cyclomatic_complexity)).
* Une petite passe avec un analyseur statique (cppcheck, avec les options --enable=all --platform=win32A) me donne les petites erreurs suivantes :
(pas d'autres erreurs apparentes ; c'est plutôt un bon point !)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 [enemy.cpp:3]: (warning) Member variable 'Enemy::m_restonnerre' is not initialized in the constructor. [enemy.cpp:3]: (warning) Member variable 'Enemy::m_resglace' is not initialized in the constructor. [enemy.cpp:3]: (warning) Member variable 'Enemy::m_resfeu' is not initialized in the constructor. [enemy.cpp:3]: (warning) Member variable 'Enemy::m_reseau' is not initialized in the constructor. [enemy.cpp:3]: (warning) Member variable 'Enemy::m_ressacre' is not initialized in the constructor. [smap.h:79]: (style) The function 'hasTeleportAt' is never used
* Le constructeur de Personnage prend trop de paramètres (12). Idem pour Player (8). Idem pour SMonstre. L'idéal est un nombre réduit de paramètres (<=4).
* on ne passe jamais les std::string par valeur ; on les passe par référence constante (const std::string&). Au niveau du code à écrire, ça ne change rien d'autre - et au niveau de l'exécution, on passe un pointeur plutôt qu'une copie d'un objet (qui impose l'utilisation du copy ctor).
* au niveau architecture logicielle, je ne sais pas si un player est un personnage. Un player a un avatar, et cet avatar est une créature, mais de la à faire le lien direct d'héritage entre player et personnage, c'est peut-être exagéré. Je mettrais plutôt les choses sous cette forme :
player et enemy sont donc très proche - sauf que l’ennemi n'évolue pas (sauf cas très, très particulier ; auquel cas on peut rajouter une classe evolving_enemy...).
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 a player has an avatar has a position has an equipment evolves ... an avatar has characteristics evolves (exemple: void player::levelup() { m_avatar->levelup(); }) ... an enemy has an avatar has a position has an equipment ...
Ceci dit, c'est une opinion personnelle. En tout cas, SMonstre n'est certainement pas une structure.
* Le prefixe S pour structure n'est vraiment pas utile.
Je reviendrais plus tard avec d'autres infos.
[FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.
Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.
Partager