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" ?