Structure de projet C++ sous Visual Studio 2008

Question

Donc, je fais Java depuis un certain nombre d'années maintenant, mais maintenant je commence un projet C++. J'essaie de déterminer les meilleures pratiques pour mettre en place ce projet.

Dans le projet, comment gérez-vous généralement leur code? Le faites-vous en style Java avec des dossiers d'espaces de noms et décomprimez votre source de cette façon? Conservez-vous vos en-têtes publics dans un répertoire d'inclusion pour faciliter le référencement?

J'ai vu les deux et d'autres moyens mentionnés, mais quelle est une bonne méthode pour un grand projet?

En outre, comment gérez-vous les ressources/dossiers dans votre structure d'application? C'est bien beau pour le projet final d'installer avec un dossier log pour stocker les journaux, peut-être un dossier lib pour les fichiers de bibliothèque, peut-être un dossier data pour les données, mais comment gérez-vous ces bits dans le projet? Y a-t-il un moyen de définir cela alors quand vous construisez la solution, elle construit la structure pour vous? Ou, devez-vous simplement aller dans vos dossiers de configuration construits (Debug, Release, etc.), et construire la structure de fichier manuellement, assurant ainsi que les chemins que votre fichier EXE s'attend à trouver sont correctement positionnés?

Answer 1

Nous avons tendance à faire de chaque composant une solution, contenant un ou plusieurs projets (ou sous-composants) et un projet de test. Le projet de test contient tous les tests unitaires.

Nous organisons ensuite les solutions dans un arbre en fonction des modules et des composants, par exemple:

//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution 

La solution contiendra alors plusieurs projets Visual Studio:

//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution/Something 
//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution/SomethingElse 
//depot/MyProject/ASubSystem/AComponentOfTheSubSystem/ASubComponentWithAVSSolution/TestTheSolution 

Il pourrait y avoir plus de profondeur à l'arbre, ou moins, selon le nombre de composants/sous-composants qu'il y a. Nous avons également tendance à avoir une solution «générale» au niveau du sous-système et du sous-composant avec des éléments réutilisables en général. Nous avons ensuite une solution au niveau du sous-système qui relie tout pour construire le sous-système.

Nous n'utilisons ni n'exportons vers un répertoire "include". Nous laissons Visual Studio construire et lier dans nos sandbox. Nous avons un sandbox "Release" séparé pour nous assurer de ne pas lier accidentellement la mauvaise bibliothèque.

Answer 2

J'ai une question connexe, mais différente se passant sur here ainsi. Je dis nmake, mais c'est vraiment tout système de construction: Scons, Bakefile, nmake, Ant, vcproj

La façon dont je structure généralement mon code est par "module" dans une application ou une DLL. Je n'ai pas eu tendance à utiliser les espaces de noms, mais cela ne veut pas dire que vous ne devriez pas.

Au sein de l'IDE j'ai quelque chose comme ceci:

/solution 
    /prj1 
     /headers 
     /module1 
     /module2 
     /resource 
     /source 
     /module 1 
     /module 2 
     /test 
    /prj2 
     /headers 
     /module1 
     /module2 
     /resource 
     /source 
     /module 1 
     /module 2 
     /test 

Sur le système de fichiers que j'ai quelque chose comme ceci:

/solution 
    /prj1 
     /bin 
     /build 
     /include 
      /module1 
      /module2 
     /lib 
     /res 
     /src 
      /module1 
      /module2 
     /test 
    /prj2 
     /bin 
     /build 
     /include 
      /module1 
      /module2 
     /lib 
     /res 
     /src 
      /module1 
      /module2 
     /test