Discussion :

[Lavock]

Bonjour, voilà je suis actuellement entrain de développé un projet contenant un grand nombre de classe, dont des interfaces, des bibliothèques d'utilitaire local (comprenez des STLs réduite et très spécialisé), plusieurs niveaux d'abstraction, etc...

Bref, pour organiser le codage du projet, j'ai une arborescence. Sauf que celle si ne me convient pas... Je trouve quelle manque de clarté... Et j'ai l'impression de ne pas exploité correctement les possibilités de ma chaine (GNU).

Après plusieurs essaie de réorganisation, je ne suis toujours pas satisfait du squelette de mon projet. Existe-t-il des "bonne pratiques" pour cela ? Si oui, quelles sont-elles/où puis-je les trouver ?

Sinon, comment gérer cela pour avoir quelque chose de décents ? Ne séparer que par des dossiers ? Faire des lib*.a/.so ou que des .o ? Selon quelle critère puis-je orienté ma découpe ?

Voilà merci d'avance !

[screetch]

salut,

ca depend surtout de ton type de projet, mais la division en repertoires est (je trouve) capitale pour avoir une pyramide de module (et non un graphe imbuvable de dépendances parfois cycliques)

je m'esplik

la premiere possibilité est de mettre toute les sources dans un repertoire src/ et tous les includes a coté ou dans un repertoire include/.
alors tous les sources sont compilés en un seul executable et peuvent dependre les unes des autres.

Une division correcte en repertoires permet de degager des modules (des groupes de sources qui "travaillent ensemble), une API se degage sur ces modules (il y a des petites classes helper dont on ne se sert que dans ce module, etc) et des liens entre les modules (de préférence des liens simples)


apres une certaine analyse j'ai décidé donc de diviser mon proejt en repertoires et de construire une DLL (un .so) pour chaque repertoire (ceci est changeable dans le makefile pour faire un executable statique)
le makefile decrit les dépendances entre les repertoires
chaque repertoire projet contient trois repertoires :
src/ pour les sources
include/ pour les includes privés (ceux qu'on est pas sensé utiliser en dehors du module)
api/ pour les fichiers include importés par d'autres modules
le Makefile se chargeant de mettre les macros qui vont bien pour les __declspec(dllexport/import)

il est alors impossible de faire une dépendance cyclique car les libs doivent etre liées, ce qui rend les modules tres clairs et indépendants.

Quant a trouver les modules en question, ca ca dépend du type de logiciel et de l'architecture que l'on souhaite avoir evidemment.

[Lavock]

Ca fait un bail, mais merci !

Toutefois, si l'arbre est "batard" i.e. (je vais eesayer de faire ça bien ) :

________Interface0________
|***********|*********|
Interface1****|*****Interface2
|*****|*****|****|*******|
Impl *Help1***|****|******Impl
*********** |_____|
*********** |
********* Help2

Et que, dans la mesure du possible, je ne veux que des librairie statiques ?

Et si jamais un de mes dossiers possèdes une référence cyclique local ?
(^=> dans mon cas, il s'agit "juste" d'une relation d'amitié de l'agrégé à son agrégant, qui serait entre autre assimilable avec "help2").

[koala01]

Salut,

Au niveau des dossiers, je dirais qu'il me semble déjà intéressant de créer une arborescence pour la partie "métier" et une autre pour la partie "utilisateur"

Cela pourrait prendre la forme de quelque chose comme

Code :

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

1
2
3
4
ProjectDir
    |- core
    |- IHM
    |-testsuite

Ensuite, chaque sous dossier(core et IHM) pourrait intelligemment être subdivisé de manière à séparer les différents points de vue, par exemple, en respectant l'arborescence des espaces de noms particuliers que tu envisage...

Le dossier core pourrait par exemple donc etre composé sous la forme de

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
core
    |-base
    |    |-privateStuff
    |-sounds
    |    |-privateStuff
    |-AI
    |    |-NPC
    |    |-nonNPC
    |    |-privateStuff
    |-persistance
    |    |-privateStuff
    |-inventory
    |-game
    |-drawing
...

(privateStuff correspondant à... ce qui sera à usage interne uniquement, par exemple)

Tu peux également envisager de créer un sous dossier include contenant les en-tête à installer et un dossier src contenant, outre les fichiers d'implémentation de la partie qui t'intéresse, les fichiers d'en-tête qui ne sont pas destinés à être fournis à l'utilisateur final

Pour ce qui est de la création de bibliothèques, rien ne t'empêche de créer une bibliothèque par... dossier de code source, même si elle n'est pas destinée à être fournie telle-quelle.

Cela te permettra de recourir aux différentes bibliothèques uniquement en cas de besoin, tout en minimisant le risque de voir des dépendances circulaires arriver...

Pour les dossiers "intermédiaires" (tels que base, sound ou AI selon

• l'exemple), tu peux envisager de créer deux bibliothèques:
• une première, partielle, ne regroupant que ce qui ne fait pas partie des différents sous dossier
• une autre plus complete, regroupant les fichiers objets des sous dossiers qui sont destinés à... être fournis à l'utilisateur

De cette manière, tu devrait arriver, non seulement, à garder une arborescence finalement cohérente et "facile d'emploi", mais aussi à obtenir l'obtention d'une "granularité" des différentes parties adaptable aux conséquences.

Enfin, pour ce qui en est du choix entre bibliothèque statiques ou bibliothèques dynamiques, j'aurais tendance à dire que les dossiers très spécialisés (base/privateStuff, par exemple) sont de bons candidats à la création de bibliothèques statiques et que les dossiers plus génériques (base, AI ou sound, par exemple) sont adaptés à la création de bibliothèques statiques aussi bien que dynamiques...

[Lavock]

Merci pour les infos, et leur clarté !

Toutefois, une précision que j'aimerai avoir. Pour les librairie "intermediaire" (AI, sound, base), en admettant que tu es besoin de base dans AI, comment ferais-tu ?

D'après ce que j'ai compris, tu ferai une bibliothèque pour AI et une pour Base. Cela me semble logique, mais la bibliothèques AI, ça serai (1)AI "seul" ou (2)AI + Base ?

Dans le cas 1, je suppose que la compilation de mon application devra appelé les bibliothèques dans "l'ordre" ( g++ -o appli.exe -L"chemin" -lBase -lAI) ?

Dans le cas 2, là par contre, je fais comment ? Du coup, le cas 1 me semble meilleurs. Je devrai toutefois spécifier quelque par les dépendances. Me trompe-je ?

Par contre, en cas de référence cyclique, là, je suis mal non ?

[EDIT]
A bien y réfléchir, mon principal problème est que dans mon "arbre" de dépendance, souvent une feuille à plusieurs parent. C'est cette situation qui me gêne particulièrement.

[Lavock]

Mais bon, c'est crasseux au possible et c'est un nid à emm.... si tu as des dépendances [...] imbriquées, c'est hautement dépendant du compilateur utilisé, ...

Déjà, est-ce qu'une "dépendance imbriquée", c'est le fait qu'un fichier objet appelle les méthode d'un autre fichier objet de la même librairie ?

En quoi c'est vraiment gênant les "dépendances imbriquées" ?