Discussion :

[remjg]

Bonjour,

J'essaie depuis quelque temps de découper mon projet c++ en plusieurs sous-fichiers, et après pas mal de recherches et d'essais, j'avoue être encore bien embrouillé!

En fait j'ai voulu mettre dans un fichier d'en-tête "figure.h" les variables globales, constantes, prototypes de fonctions pour gérer un menu, et mes prototypes de classes, afin d'avoir un bon aperçu de mon programme.

J'ai ensuite défini mes fonctions et classes dans un fichier "figure.cpp" qui inclut "figure.h"

Enfin, un fichier "main.cpp" contient ma fonction main() et utilise certaines des variables globales.

Je me retrouve avec plein d'erreur à l'édition des liens me disant que mes variables sont définis plusieurs fois. Que dois-je faire alors? Définir mes variables globales dans mon fichier figure.cpp et utiliser le mot-clef extern dans "main.cpp" pour les utiliser?

Si quelqu'un a une doc très complète afin d'organiser un programme c++ je serais preneur!
Merci d'avance,

Rémi.

[JolyLoic]

Très complète, probablement pas assez, mais j'avais écrit ce bout de doc à une époque. J'espère qu'il peut aider :
http://loic-joly.developpez.com/arti...tifichiers.pdf

[remjg]

Merci beaucoup, cela aborde tous les sujets qui me posent problème. J'ai besoin de faire des essais maintenant!

Car en fait, le principal problème de mon programme, c'est l'interdépendance de mes classes avec mes menus (mon projet est de concevoir un petit programme de géométrie dynamique utilisant freeglut et glui pour l'interface).

Dans mes fonctions gérant l'interface, j'ai besoin de mes classes, mais j'ai aussi besoin d'agir sur mes menus depuis mes classes notamment par le biais des variables globales... Un peu complexe pour un débutant comme moi!

En tout les cas, le tableau 6.1 page 51 devrait s'avérer très utile!

[remjg]

Donc j'ai réussi à découper mon programme en plusieurs fichiers.

En simplifiant, cela donne ceci :
- a.h & a.cpp (gestion de mes menus avec glui)
- b.h & b.cpp (gestion de l'affichage et freeglut)
- c.h & c.cpp (plusieurs classes)
- main.cpp (contenant main())

Au niveau des inclusions j'ai ceci :
- a.h et b.h incluent c.h
- a.h et b.h partagent des variables (déclarées avec le mot clef extern) et des fonctions.
- main.cpp inclut a.h et b.h

J'ai l'impression qu'en voulant rendre mon programme plus claire, j'ai compliqué les choses. Vu que a.h et b.h partagent beaucoup de données, serait-il plus logique de les fusionner tout en gardant a.cpp et b.cpp bien séparés?

Merci d'avance! Je sais pas si ça se voit en me lisant mais je suis un peu pommé...

[remjg]

En fait, pour 2 fichiers d'en-tête a.h et b.h implémenté dans a.cpp et b.cpp partageant des données communes (variables globales et fonctions), je vois trois possibilités (par avance désolé si je n'utilise pas le vocabulaire approprié) :

1) a.h et b.h contiennent uniquement les déclarations des définitions se trouvant respectivement dans a.cpp et b.cpp.
Il faut alors inclure au début de a.cpp et b.cpp les deux fichiers d'en-tête.
- Avantage : facile à mettre en oeuvre puisqu'il n'y a pas besoin de déclarer ce qui provient de l'autre header.
- Inconvénient : a.cpp et b.cpp ne sont pas indépendants à la compilation.

2) a.h contient les déclaration des définitions se trouvant dans a.cpp ainsi que toutes celles nécessaires provenant d'autres fichiers sources. De même pour b.h.
- Avantage : il est facile de voir de quelles variables globales / fonctions dépend a.cpp. De plus a.cpp et b.cpp sont indépendant à la compilation.

3) Solution lue sur cette page :
a.h contient toutes les déclarations nécessaires à la compilation de a.cpp tandis que b.h contient uniquement les déclaration de définitions de b.cpp.
- Avantage : a.h est indépendant de b.h

Dans mon cas, j'ai appliqué la solution 2. Qu'en pensez-vous?

Aussi, je voulais savoir :
Où dois-je inclure les autres headers dont j'ai besoin comme <iostream> etc... dans chaque fichier *.cpp qui en a besoin? ou dans les headers?

Merci d'avance pour vos réponses! J'ai conscience que c'est un peu lourd à lire!

Rémi.

[koala01]

Salut,

En fait, pour 2 fichiers d'en-tête a.h et b.h implémenté dans a.cpp et b.cpp partageant des données communes (variables globales et fonctions), je vois trois possibilités (par avance désolé si je n'utilise pas le vocabulaire approprié) :

1) a.h et b.h contiennent uniquement les déclarations des définitions se trouvant respectivement dans a.cpp et b.cpp.
Il faut alors inclure au début de a.cpp et b.cpp les deux fichiers d'en-tête.
- Avantage : facile à mettre en oeuvre puisqu'il n'y a pas besoin de déclarer ce qui provient de l'autre header.
- Inconvénient : a.cpp et b.cpp ne sont pas indépendants à la compilation.

2) a.h contient les déclaration des définitions se trouvant dans a.cpp ainsi que toutes celles nécessaires provenant d'autres fichiers sources. De même pour b.h.
- Avantage : il est facile de voir de quelles variables globales / fonctions dépend a.cpp. De plus a.cpp et b.cpp sont indépendant à la compilation.

3) Solution lue sur cette page :
a.h contient toutes les déclarations nécessaires à la compilation de a.cpp tandis que b.h contient uniquement les déclaration de définitions de b.cpp.
- Avantage : a.h est indépendant de b.h

Dans mon cas, j'ai appliqué la solution 2. Qu'en pensez-vous?

J'en pense que, si tu nous donnais le code source réel, cela nous aiderait énormément à te dire ce que nous en pensons

Aussi, je voulais savoir :
Où dois-je inclure les autres headers dont j'ai besoin comme <iostream> etc... dans chaque fichier *.cpp qui en a besoin? ou dans les headers?

Merci d'avance pour vos réponses! J'ai conscience que c'est un peu lourd à lire!

Rémi.

Tu dois inclure les fichiers d'en-tête externes à ton projet (je parle, par exemple de ceux de glut ou ceux fournis par le standard) le plus tard possible:

• dans le fichier d'implémentation (*.cpp) si tu n'a pas besoin de ce qu'il déclare dans le fichier d'en-tête (*.hpp)
• Dans le fichier d'en-tête (*.hpp) si tu dois déclarer une variable dont le type correspond à ce qu'il déclare

[gl]

En fait, pour 2 fichiers d'en-tête a.h et b.h implémenté dans a.cpp et b.cpp partageant des données communes (variables globales et fonctions), je vois trois possibilités (par avance désolé si je n'utilise pas le vocabulaire approprié) :

1) a.h et b.h contiennent uniquement les déclarations des définitions se trouvant respectivement dans a.cpp et b.cpp.
Il faut alors inclure au début de a.cpp et b.cpp les deux fichiers d'en-tête.
- Avantage : facile à mettre en oeuvre puisqu'il n'y a pas besoin de déclarer ce qui provient de l'autre header.
- Inconvénient : a.cpp et b.cpp ne sont pas indépendants à la compilation.

2) a.h contient les déclaration des définitions se trouvant dans a.cpp ainsi que toutes celles nécessaires provenant d'autres fichiers sources. De même pour b.h.
- Avantage : il est facile de voir de quelles variables globales / fonctions dépend a.cpp. De plus a.cpp et b.cpp sont indépendant à la compilation.

3) Solution lue sur cette page :
a.h contient toutes les déclarations nécessaires à la compilation de a.cpp tandis que b.h contient uniquement les déclaration de définitions de b.cpp.
- Avantage : a.h est indépendant de b.h

Dans mon cas, j'ai appliqué la solution 2. Qu'en pensez-vous?

Globalement, que ce n'est pas la bonne solution. Généralement, on utilise plutôt une solution proche de 1 avec en respectant également les points suivants :

• On n'inclue pas tout les .h dans tous les .cpp, seulement ce qui est nécessaire.
• Un .h doit être autonome, s'il a besoin d'un autre .h, le second est inclue dans le premier.

Cette solution :

• Ne lie absolument pas a.cpp et b.cpp. Elle fait juste dépendre l'utilisateur (ainsi que l'implémentation) de l'interface. Ce qui est justement le rôle des header. Et au passage, tu as la même dépendance dans les deux autres solutions, si ce n'est qu'elle est dispersée.
• Est beaucoup plus simple à maintenir : si tu modifies ou rajoutes une fonction publiques dans a.cpp, tu n'as qu'un fichier .h à mettre à jour.
• Les interfaces sont clairement définies, regroupées logiquement et localisées et non pas dispersé dans n fichiers.
• Correspond à l'usage général.

Après c'est une règle "générale" et il peut y avoir des exceptions tout à fait légitime dans certains cas particuliers.