J'ai un projet qui possède la structure de répertoire suivante.
#include <module1/foo.h>
7 Réponses :
Je préfère beaucoup la 2e façon Je trouve que cela rend la source beaucoup plus facile à regarder. Le problème est que, lorsque d'autres personnes viennent consulter votre code, ce n'est pas nécessairement inhérent à l'emplacement du fichier d'en-tête, tandis que la première façon d'inclure est.
Chaque style a quelques inconvénients, mais je préfère celui que vous avez spécifié. Le chemin inclus ne doit contenir aucune relativité ascendante (telle que ../ .. ) et doit spécifier le module qu'il repose.
#include <h-char-sequence> new-line`
Des conseils sur la façon d'éviter de créer des "backtracking" (..) dans les spécificateurs d'en-tête?
@Skurmedel: voulez-vous dire des chemins relatifs qui pointent sur des en-têtes déclarés à un niveau ancestral? Je suis tenté de penser que l'en-tête du compilateur inclut l'option et / ou une séparation correcte des préoccupations toujours corrigées. Sauf bien sûr, dans quelques cas très rares. E.g: code hérité - où vous ne pouvez tout simplement pas changer la conception du module, même si vous le souhaitez.
Oui. Si je comprends
Oh, maintenant je vois ce que tu veux dire. Il semble que mon problème est que je ne sépare pas le dossier Include et source, je les ai surtout fusionnés. Il est temps de s'arrêter avec cette habitude.
@Skurmedel: Oui, c'est un bon habit (TM)!
comme un petit raffinement, je vous suggère d'autoriser des fichiers ou similaire. Cela créera un effet visuel dans vos fichiers C qui distingue les inclusions étrangères à partir de la valeur par défaut incluent: cc dans le module1 pour accéder directement à leurs fichiers .h directement:
Guide de style C ++ de Google a un section sur cette où ils discutent de la commande et de la nommage de l'inclut. Il est essentiellement d'accord avec ce qui a été dit dans les autres réponses jusqu'à présent, mais cela vaut la peine d'avoir un coup d'oeil tel qu'il est très spécifique.
Je préfère (et Google accepte) de ne pas avoir de chemins relatifs en utilisant. Dans les directives Inclure. Votre évaluation initiale qu'il a l'air propre est correcte. Avoir des chemins relatifs longs, maladroits et relatifs rend les choses plus difficiles à lire et plus difficiles à refacteur. Je pense que votre approche est correcte.
En ce qui concerne la source de séparation et inclure des fichiers en deux sous-arbres différents: pourquoi ne pas avoir les en-têtes vivent à côté des fichiers source? Cela facilite la correspondre à eux. Sauf si vous vous attendez à ce que d'autres projets utilisent vos en-têtes et que vous vous trouvez simplement à vos fichiers binaires, je suppose.
D'autres projets réutilisant votre code sont difficiles à connaître à l'avance, alors la séparation est meilleure, je pense :)
Je supporte les deux styles ... Pour différentes utilisations
Supposons que vous ayez également un répertoire Je préfère ne pas voir le répertoire "Inclure", comme indiqué bien sûr, il est donc plus difficile de localiser le fichier d'en-tête exact ... Mais lorsque vous commencez et déplacez-vous vers plusieurs bibliothèques indépendantes, vous devez résumer car vous souhaitez pouvoir déplacer les différents composants sans modifier le code, et je suis tout pour la cohérence. P> aussi, il y a toujours le risque utilisant ".." que cela ne va pas où vous pensiez à cause d'un lien symbolique traversé vers l'arrière: / p> Source fort> p> Parfois, vous avez des en-têtes Ce ne sont pas publics et non dans le répertoire code> code>. Celles-ci sont généralement pour les détails de la mise en œuvre qui ne sont pas pertinents pour vos clients. Pour ceux que j'utilise le Ceci permet:
- ne pas encombrer le strong> p> si je dois taper p> alors je m'attends à utiliser: p> ce qui facilite la correspondre à un type particulier à un module particulier. P> L'exigence Une bibliothèque - un espace de noms, avec des noms identiques, facilite la navigation sur les composants d'environ 300 ou ~ 400 que nous avons au travail: nous avons dû trouver un moyen de les organiser! P> Cela signifie que ce que votre mise en page initiale soit retravaillée (pour le projet Code> Module Code>): P> root / src / commun code> à des fins de mon exemple p> .. code> si besoin d'être et précisez l'emplacement exact. P> -i code> avec tous les répertoires possibles de src code>
- localiser facilement le fichier parmi vos sources
- Testez facilement tester les dépendances entre vos sources (GREP pour .. code>) p> root
-- include
---- module
------ part1
------ part2
-- src
---- part1
---- part2
Je n'utilise pas les chemins dans ils le feront. Votre hiérarchie changera. Vous voudrez peut-être mettre les fichiers sur un autre lecteur. Ils peuvent changer de lieu lorsqu'un autre utilisateur modifie votre code. Les fichiers peuvent se déplacer lorsqu'ils sont portés pour un autre projet. Rien n'empêche vos fichiers de bouger.
Savoir que les fichiers se déplaceront, si le chemin est dans le fichier, le fichier doit être modifié lorsqu'il est déplacé. Sans le chemin dans le fichier, seules les instructions de construction doivent changer. Avec de grands projets, la modification de nombreux fichiers est une douleur (même avec des scripts).
À mon avis, les chemins dans #include directives. D'après mon expérience, ils causent toujours des problèmes dans la phase de maintenance. De nombreux compilateurs vous permettent de spécifier l'arborescence de recherche pour les fichiers d'en-tête.
Les fichiers peuvent déplacer
Déplacement de fichiers sans les modifier
#include Les directives sont diaboliques. Les personnes qui le font devraient être recyclées ou envoyées à d'autres entreprises.
Et si, disons, vous développez un substitut de chaîne et souhaitez toujours utiliser STD :: Carte? Les chemins dans les en-têtes sont essentiels. Mais certaines personnes ont tendance à éviter d'utiliser des couteaux, car ils peuvent tuer.
Les chemins dans #include ne sont pas essentiels. Je travaille sur mon propre projet depuis de nombreuses années et aucun des #include a des chemins. J'ai le compilateur mis en place pour rechercher de nombreux répertoires. Dans la plupart des procédures de construction, vous pouvez indiquer par des annuaires de fichier à rechercher. Le paramètre de ligne Common Command est -i . J'ai même std :: map de wxstring . Ni la #include pour wxstring nécessitent des chemins dans le #include .