Dossiers "include" et "src" séparés pour le code au niveau de l'application?
Cette question concerne principalement le développement C++ de style Unix/Linux. Je vois que beaucoup de C++ bibliothèques stockent leurs fichiers d'en-tête dans un dossier "include" et les fichiers source dans un dossier "src". Par souci de conformité, j'ai adopté cela dans mon propre code. Mais il n'est pas clair pour moi si cela doit également être fait pour le code application. J'ai vu quelques cas où une structure de répertoire plate est utilisée pour cela. Quelle serait l'approche recommandée?
Je les sépare également, mais pas strictement sur l'extension, mais sur l'accès au fichier.
Supposons que vous ayez un module qui gère les informations client et utilise 2 classes pour ce faire: Customer, CustomerValidityChecker. Supposons également que les autres parties de votre application n'aient besoin que de connaître la classe Customer et que CustomerValidityChecker n'est utilisé que par la classe Customer pour effectuer des vérifications. Sur la base de ces hypothèses, je stocke les fichiers comme ceci:
Dossier public (ou dossier inclus):
- customer.h
Dossier privé (ou dossier source):
- customer.cpp
- customervaliditychecker.h
- customervaliditychecker.cpp
De cette façon, il devient immédiatement clair pour les appelants de votre module quelles parties sont accessibles (publiques) et quelles parties ne le sont pas.
Nous avons un système de génération qui génère automatiquement nos makefiles. Une chose qu'il fait est de descendre récursivement tous les sous-répertoires et de les créer en tant que bibliothèques, en les liant avec les objets du répertoire principal pour créer l'application. (En pratique, ces "sous-répertoires" sont généralement des liens symboliques.) Les bibliothèques sont statiques, sauf si le nom du répertoire se termine par ".so". Une chose intéressante à ce sujet est qu'une version complète de notre système, qui contient de nombreux exécutables, n'a pas à compiler à plusieurs reprises les bibliothèques communes.
Cependant, à la suite de cela, il n'y a pas de séparation des en-têtes et des sources. Et ça n'a jamais été un problème. Honnêtement, je pense que c'est mieux de cette façon parce que les en-têtes et les fichiers source ont un emplacement commun, et vous pouvez récupérer un répertoire et savoir que vous avez tout ce dont vous avez besoin pour l'utiliser. Il fonctionne également très bien avec la fonction "externes" de Subversion et des fonctionnalités similaires dans d'autres VCS.
Un dernier endroit où une séparation include/src échoue est si vous utilisez des générateurs de code, tels que flex, bison ou gengetopts. Il est difficile de déterminer où ces outils doivent mettre leurs sorties pour qu'elles soient construites si vous avez réparti les choses.
Il est logique de les séparer pour les bibliothèques partagées car elles peuvent être distribuées sous une forme compilée sans la source. J'ai vu des projets qui séparent les en-têtes "publics" (en-têtes auxquels on peut accéder à partir du code en dehors de votre projet ou bibliothèque) tout en laissant les en-têtes "privés" et les fichiers source dans le même répertoire. Je pense qu'il est bon d'utiliser une approche cohérente que vous écriviez une bibliothèque partagée ou un code de niveau application, car vous ne savez jamais quand vous voudrez peut-être transformer quelque chose que vous avez écrit au niveau de l'application en une bibliothèque de niveau inférieur partagée par plusieurs projets.
Cela dépend beaucoup de la taille du projet impliqué. Jusqu'à quelques dizaines de fichiers environ, les conserver dans un seul répertoire a tendance à être plus pratique. Pour une application plus grande qui comprend des centaines ou des milliers de fichiers, vous commencez à chercher des moyens de les séparer (bien que dans les projets sur lesquels j'ai travaillé, cela ait été fait plus sur des lignes fonctionnelles que src/include). Entre ceux-ci, il est probablement question.
Je ne fais pas ça; il semble y avoir peu d'avantages. Étant donné que les en-têtes ont généralement une extension différente des fichiers source, vous pouvez demander à votre éditeur de les afficher séparément si vous en ressentez vraiment le besoin - Visual Studio le fait par défaut, mais je le désactive car je préfère les voir ensemble
À mon avis, il n'y a aucun avantage clair pour les deux. J'ai finalement décidé de garder le programme et les fichiers d'en-tête ensemble parce que mon éditeur (Visual SlickEdit) fournit des fonctionnalités référentielles supplémentaires lorsqu'elles ne sont pas séparées.
Je crée presque toujours des dossiers include et src pour diviser mon code source. Je pense que cela rend le dossier moins encombré et les fichiers sont plus faciles à trouver dans mon IDE. Mais je pense que c'est juste une question de goût.
L'une ou l'autre méthode est valide. Cela dépend du style de codage que vous souhaitez suivre.
Bottom Line: les sources et les en-têtes qui changent encore vont dans /src. Le code qui s'est cristallisé devrait aller dans /lib & /include (en fait, vous pouvez conserver tous les .libs et leurs .hpéché /lib).
- Gardez vos propres sources et en-têtes ensemble, à condition qu'ils soient (a) spécifiques à ce projet ou (b) n'ont pas encore été factorisés en tant que bibliothèque partagée.
- Une fois que certaines sources du projet principal ont été factorisées comme une bibliothèque (relativement stable), placez le
.aou.liben/lib, et son en-tête d'interface publique dans/include. - Toutes les bibliothèques tierces et leurs en-têtes d'interface publique vont également dans
/lib&/include.
Comme d'autres le notent, il est souvent plus compatible pour les outils/IDE d'accéder à .h/.c à partir d'un dossier. Mais d'un point de vue organisationnel, il peut être utile de séparer le code local changeant du code lib stable.
Je place les fichiers source (en-tête) et source dans le même répertoire (dossier). Je crée différents dossiers pour différents thèmes. Je suis frustré lorsque j'essaie de trouver des fichiers d'en-tête (lors du débogage et également pour la recherche). Dans certains magasins, il n'y a que deux dossiers: source et includes. Ces répertoires ont tendance à croître de façon exponentielle. Réutiliser le code devient au mieux un cauchemar.
À mon humble avis, je pense que l'organisation par thème est meilleure. Chaque dossier de thème doit être intégré dans au moins une bibliothèque. Différents projets peuvent facilement inclure les thèmes en recherchant ou en incluant les dossiers. Les projets doivent uniquement inclure les bibliothèques. Les moteurs de génération intelligents peuvent répertorier les dossiers de thèmes en tant que dépendances. Cela accélère le processus de construction.
L'organisation thématique ajoute également un peu de sécurité au projet. Les dommages accidentels aux fichiers (tels que la suppression des mauvais ou le remplacement par des versions différentes) sont réduits car les fichiers se trouvent dans des répertoires différents. La suppression de fichiers dans le dossier "Personne" n'affectera pas les fichiers dans le dossier "Forme".
Ceci est juste mon opinion, votre kilométrage peut varier.
Nous avons un système de build qui utilise cette règle. Ce système de build est sconspiracy un ensemble de scripts pour configurer SCons et dédié au monde C++. Vous pouvez voir un exemple qui utilise ces outils: fw4spl