Problème de structuration au niveau des includes

**xwindoo** · 17/08/2006, 19h27

J'ai quelques problèmes de structuration des fichiers au niveau des includes :

Code :

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

1
2
3
 
// a.h 
#include "b.h"

Code :

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

1
2
3
 
// b.h 
#include "a.h"

Est ce que quelqu'un pourais me donner un remède a cela. ?

**Pragmateek** · 17/08/2006, 19h42

"a.h":

Code :

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

1
2
3
4
#ifndef A
#define A
...
#endif

"b.h":

Code :

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

1
2
3
4
#ifndef B
#define B
...
#endif

ce qui évitera l'inclusion infinie.

**xwindoo** · 17/08/2006, 19h58

Merci pour ta réponse, Je n'y avait pas pensé plutot, et pourtant, je l'utilise avec les classes...
Est ce que c'est possible de faire pareil pour les fichier cpp ?

**roulious** · 17/08/2006, 20h13

Envoyé par xwindoo

Est ce que c'est possible de faire pareil pour les fichier cpp ?

Oui, mais c'est en général une mauvaise idée d'inclure des fichiers cpp. Si tu parles d'une dépendance entre deux classes (A a besoin de la déclaration de B et vice-versa), soit tu peux utiliser une déclaration anticipée (forward declaration), soit tu as un problème de conception quelque part.

**xwindoo** · 17/08/2006, 21h27

désolé, je me trompé, je pensais à inclure un fichier h dans un cpp mais la le problème se pose pas en effet. Pour la déclaration anticipé, c'est parfois difficile a mettre en place. Et pour le problème de conception, j'ai toujours (enfin, ca fait pas des lustre que j'ai commencé a programmer) eu des soucis d'organisation dans les programme relativement gros (2000 lignes, 10 fichiers, c'est ce que je fais). Merci pour ta réponse.

**dockurt2k** · 17/08/2006, 23h34

Deux conseils pour éviter tout probléme notamment de dépendance cyclique :
-toujours faire une conception pour les projets qui utiliseront plus de 2 ou 3 classes (modélisation UML, diagramme de classe par exemple)
-de maniére plus plus technique, tu peut essayer de Programmer Orientée Composant. Dans ton cas précis définit une classe d'interface pour une des deux classes (voir les deux).

Exemple précis:

ia.h

Code :

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

1
2
3
4
5
class IA
{
public :
virtual void Do_It()=0;
};

a.h

Code :

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

1
2
3
4
5
6
#include "ia.h"
class A : public IA
{
public :
virtual void Do_It();
}

b.h

Code :

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

1
2
3
4
5
6
#include "ia.h"
class B
{
public:
void Do_Something_WithA(IA *);
}

Ainsi B n'a pas besoin de connaitre A, elle connait juste une interface de A.
Autre avantage, tu peut changer l'objet implémentant IA sans modifier B du tout...

BRef c'est un peu lourd pour les petits cas mais c'est extrémement puissant

**xwindoo** · 19/08/2006, 11h38

Merci pour ta réponse dockurt2k.
Comme faire de ma modélisation UML ? j'ai cherché un peu sur internet, pas longtemps certe, mais j'ai pas trouvé ce que c'étais exactement, si tu pouvais m'expliquer.

**dockurt2k** · 19/08/2006, 12h01

UML : Universal Modeling Language
C'est un langage graphique qui permet de modéliser en théorie à peu prés tout. En pratique c'est utilisé en informatique (du moins pour le moment) pour modéliser des applications avans dévellopement (aussi en cours et aprés mais d'autres raisons) et des bases de données. Cette modélisation est basé sur la notion d'objets.

Le but c'est de réfléchir à l'architecture et à la maniére de fonctionner de l'application avans d'écrire la moindre ligne de code. Ainsi l'écriture du code en lui même doit devenir une simple formalité ou il n'est plus guére besoin de réflechir.

Pour cela l'uml propose un certain nombre de diagrammes (15 en UML 2.0 je croit) permettant la modélisation.

Pour commencer je te conseille de te renseigner et d'utiliser les diagrammes de classe et de séquence.
Autre conseil,ne t'inquiéte pas si les cours te paraissent trop rigide. N'hesite pas à utiliser la modélisation à ta sauce, il faut que ca te parle à toi (et à ton équipe si tu n'est pas tout seul).

Le site Cours et tutoriels pour apprendre UML surtout celui la est parfait : Cours complet pour apprendre UML 2.0, une série de tutoriels par Laurent Audibert
(je vient de tomber dessus pour te trouver une adresse)
Tu trouvera notamment la partie du cours consacré au diagramme de classe

Le logiciel de modélisation UML que j'utilise est ObjecteeringUML dont une version gratuit à usage privée est disponible.
RationalRose est sans doute le logiciel le plus connue mais je te le déconseille du moins pour le début.

Je vais te modéliser la petite architecture que j'ai fait plus haut et je poste ça rapidement

**dockurt2k** · 19/08/2006, 12h14

Voila l'image de l'architecture plus haut :

**Matthieu Brucher** · 19/08/2006, 16h55

Ce cours est aussi présent sur DVP : http://laurent-piechocki.developpez...._fr_cours.html
Tu trouveras dans la section UML une liste d'outils qui t'aideront. Le dictionnaire DVP - http://dico.developpez.com/ - possède aussi des définitions au cas où certains mots seraient de sens inconnu

**xwindoo** · 20/08/2006, 13h35

Merci pour vos réponses, je vais voir tout ca.

**xwindoo** · 20/08/2006, 17h04

J'ai compris de quoi il s'agissait, mais je ne voit pas l'intérêt d'un tel processus pour créer des classes, et ne comprend pas l'utilité d'un logiciel, on peu très bien le faire nous même sur papier, même sans norme... Il faut avoué aussi que je comprend difficilement Objecteering UML, et ne voit pas en quoi il pourrais aider à éliminer des erreurs au niveau du code lui-même. J'ai essayé de modèlisé la structure actuelle de mon jeu, mais ce n'est pas une réussite, ca m'a l'air plus difficile de le faire en modèlisé qu'en code... C'est peut-être parce que je ne connais pas encore suffisament l'UML.

**dockurt2k** · 20/08/2006, 18h12

et ne comprend pas l'utilité d'un logiciel, on peu très bien le faire nous même sur papier

Exactement, pour faire de l'uml pas besoin de logiciel. Il te permettent juste de vérifier tes diagrammes, les retouvher facilement. Enfin c'est pareil pour écrire un rapport tu peut le faire sur papier, mais si tu as un truc à retoucher à posteriori ...
Ma démarche classique : ecriture de broullion de diagramme sur papier ou tableau blanc quand je suis en équipe. Puis je le reproduit sur PC.

Cependant les logiciels avancé de modélisation UML te permettent de générer automatiquement tes classes à partir de diagramme de classes. Beaucoup de gens utilisent cette possibilité, personnellement je n'aime pas du tout cette maniére de faire.

ne voit pas en quoi il pourrais aider à éliminer des erreurs au niveau du code lui-même

Sur ton code en lui même (algorithme, E/S, interface ...) une modélisation ne t'apportera effectivement aucun avantage direct. Tu pourra toujours faire des erreurs de pointeurs, de compteur, ...
C'est sur l'architecture que la modélisation est importante. Le choix de ce qui doit etre un objet, de ce qui ne doit pas l'étre. La granularité de tes objets, leur "intelligence" propre.
Une bonne modélisation te permet d'arriver à ton résultat plus rapidement, avec un code plus concis, plus évolutif et dans une certaine mesure plus sure.

J'ai essayé de modèlisé la structure actuelle de mon jeu, mais ce n'est pas une réussite, ca m'a l'air plus difficile de le faire en modèlisé qu'en code

J'ai du mal à comprendre que ce soit plus dur en modélisé. Le but de ta modélisation c'est de te poser un maximum de questions le plus tot possible plutot que te retrouver coincé en plein dev à cause d'un oubli.
Par exemple pour un jeu. Les questions que tu pourrait te poser :
-est ce que chaque joueur doit être un objet
-est ce que chaque objets joueur est responsable de son propre comptage de points
-est ce que la partie Regles de Jeus et Animation est un objet, dois-je le séparer d'un objet Interface Graphique

A propos des normes, elles ne sont sans doute pas inutiles. Elles te permettent de comprendre facilement ce que les diagrammes d'autres personnes signifient sans avoir besoin d'une légende plus grande que le diagramme.

**xwindoo** · 20/08/2006, 19h57

Par exemple pour un jeu. Les questions que tu pourrait te poser :
-est ce que chaque joueur doit être un objet
-est ce que chaque objets joueur est responsable de son propre comptage de points
-est ce que la partie Regles de Jeus et Animation est un objet, dois-je le séparer d'un objet Interface Graphique

J'y bien pensé et j'y réfléchis toujours mais je me doutais nullement que ce que je faisais étais de la modélisation.
Je n'ai pas fait de dessin parce que j'ai toute ma structure en tête - je suis seul (j'ai que 14 ans donc c'est difficile de trouvé quelqu'un qui s'y interrese vraiment) donc je n'avais pas besoin de partager mes idées -, et j'écris le code au fur et à mesure : c'est peu être pour ça que je m'embrouille un peu..

Mon problème, c'est plus la relation entre chaque classes que la structuration (je me suis débrouillé jusqu'à présent ... ); notament, le problème qui ma poussé a créer ce post ainsi que losque je devais inclure une définition d'une classe parce que je devais avoir un pointeur sur cette classe, le compilateur me donnait plein d'erreurs du genre 'missing storage-class or spécifier' ou 'undeclared identifier' à cause des includes :

Code :

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

1
2
3
 
// a.h
HWND hWnd;

Code :

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

1
2
3
4
 
// a.cpp
#include <windows.h>
#include "a.h"

Par exemple, lorsque que j'incluais a.h dans un autre fichier, le compilateur me disait 'HWND : undeclared identifier'.

Deux conseils pour éviter tout probléme notamment de dépendance cyclique :
-toujours faire une conception pour les projets qui utiliseront plus de 2 ou 3 classes (modélisation UML, diagramme de classe par exemple)

Est ce que l'UML permet aussi de résoudres ces problèmes de relations entres classes ? J'ai regardé le tutorial et j'ai vu que les classes étais relié différemment mais je n'ai pas encore totalement compris ce que chacun indiquais - le vocabulaire est plutôt compliqué -.

**Matthieu Brucher** · 20/08/2006, 22h37

L'UML est un langage, un outil. Ce dont tu as besoin, c'est d'apprendre pourquoi on l'utilise, donc je te conseille plutôt de lire un livre de conception qu'un livre d'UML.

**dockurt2k** · 21/08/2006, 13h41

L'UML est un langage, un outil. Ce dont tu as besoin, c'est d'apprendre pourquoi on l'utilise, donc je te conseille plutôt de lire un livre de conception qu'un livre d'UML.

Sans doute, en tout cas cela s'inscrit dans une démarche de professionalisation de tes compétences. Ca te semblera peut être rébarbatif (en tout cas à ton age je préférait programmer sans me poser de questions), mais tache tout de même t'intéréssé aussi à cette aspect. Ca paye rapidement et c'est peut être bien plus gratifiant que de réussir à coder un algo quelconque.

**xwindoo** · 21/08/2006, 14h12

Je vais m'interresser a l'UML et essairai de continuer mon jeu avec...

Mreci pour toutes vos réponses et pour l'attention porté a ma demande !
++
XWindoo

Problème de structuration au niveau des includes

C++

Discussions similaires

Partager

Partager