Discussion :

[Bash01]

Bonjour,

Dans le cadre d'un apprentissage du C++, j'ai repris un programme Java que j'avais effectué pour le réécrire en C++.

Toutefois, je ne suis pas sûr de quel type d'arborescence adopter.

En Java, j'avais séparé les "types" d'objets en différents packages et donc quand on avait un certain package sous les yeux, on savait qu'on y trouverait que certaines classes précises.
Dois-je faire de même en C++ ?

J'ai fais un peu de C avant et je structurais en créant des répertoires src, include et bin. Dans src et include, je créeais d'autres répertoires permettant de séparer les TAD, l'IHM et la logique métier.
Dois-je aussi adopter la même structuration en C++ ?

Merci.

[Invité]

Il n'y a pas de règle précise. Dans certains langages objets, on encourage (voire force) le développeur à avoir un module (fichier+entête) par classe. Du coup, on se retrouve assez vite avec beaucoup de tout petits fichiers, qu'on organise dans un système arborescent et complexe de répertoires.

C'est faisable en C++, mais le plus souvent on fait des modules "plus gros": quelques classes qui collaborent entre elles (ou pas d'ailleurs, souvent tu finis avec un fichier "utils.cpp" qui contient tout ce que tu n'as pu mettre ailleurs), et qui communiquent avec le monde extérieur au travers d'une interface, contenue dans les fichiers entete, qu'on essaye de rendre minimale. La règle de base, c'est d'essayer d'avoir une interface aussi simple et cohérente que possible.

Quant à la taille des fichiers, c'est comme celle des fonctions: une question de gout. Il y a des gens qui considèrent que 30 lignes pour une fonction, c'est déjà trop, d'autres qui considèrent que c'est plutot au dela de 300. C'est pareil pour les modules. Je connais des programmeurs qui ne veulent rien voir au delà de 200 lignes, et d'autres qui pensent que 2000 ca va.

La question de fond, c'est de savoir si toi (et tes coprogrammeurs si tu travailles en groupe) te sent mieux dans un projet avec 25 fichiers de 2000 lignes, ou 250 fichiers de 200.

Dans le premier cas, le découpage en répertoire n'est pas nécessaire, dans le second il est indispensable.

Francois

[koala01]

Salut,

Comme l'a fais remarquer fcharton, il n'y a pas de règle définitive sur l'organisation de l'arborescence des fichiers.

Cependant, la plupart des EDI nous incitent à créer une unité de compilation par classe (une unité de compilation étant un couple *.h + *.cpp).

De plus, il existe le concept d'espace de noms en C++ qui correspond, en gros, à des "boites" dans lesquelles on regroupe tout ce qui "va bien ensemble":

Par exemple, si tu veux créer un jeu video, tu auras vraisemblablement un ensemble de classes qui travaille ensemble pour gérer les sons, un autre pour gérer l'affichage, un troisième pour gérer l'intelligence artificielle, etc.

On peut décemment estimer que chaque espace de noms risque de communiquer avec un ou plusieurs autre(s): l'espace de noms "game" risque, en effet, de communiquer avec à peu près tous les autres.

Cependant, on tentera autant que possible de limiter au maximum les "points de communications" entre les différents espaces de noms.

Ce qui s'en rapproche le plus en java, bien qu'il y ait un certain nombre de différences est la notion de package

L'habitude que j'ai prise est de créer une arborescence qui rappelle l'organisation des espaces de noms.

Ainsi, dans le dossier de mes projets, si j'ai les espaces de noms Game, AI, Sound, Screen, on trouvera des dossiers portant les mêmes noms dans lesquels les différentes unités de compilation prendront place.

Evidemment, dans chaque dossier tu trouvera au minimum un dossier include (contenant les fichiers d'en-tête) et un dossier src (contenant les fichiers d'implémentation), et sans doute un dossier test (contenant les tests unitaires), mais tu peux, le cas échéant, ajouter des dossiers "particuliers" comme priv pour contenir ce qui est à usage exclusivement interne

Maintenant, ce que fcharton a bien expliqué reste tout à fait vrai: je préfères personnellement n'avoir qu'une classe (et ses classes imbriquées, s'il y en a) par unité de compilation, ce qui tend à créer des fichiers relativement "peu importants" mais nombreux...

D'autres préféreront créer des unités de compilation regroupant plusieurs classes qui "vont bien ensemble".

Cela diminue le nombre de fichiers, mais augmente en retour d'autant la taille des fichiers