Y compris un fichier source C dans un autre?
Est-il OK (ou même recommandée/bonnes pratiques) à #include .c fichier dans un autre .c fichier? Ce qui se passe lorsqu'ils sont inclus dans un fichier de projet?
- J'ai pris la liberté de modifier la question, et également appliqué un peu de pratique balises. Certains de mes balises peut montrer un biais, heh.
Vous devez vous connecter pour publier un commentaire.
Utilisé correctement, cela peut être une technique utile.
Dire que vous avez un complexe, critique pour les performances du sous-système avec un tout petit public interface et beaucoup de non-réutilisables mise en œuvre du code. Le code s'exécute à plusieurs milliers de lignes, une centaine privé des fonctions et un peu de données privées. Si vous travaillez avec des non-trivial de systèmes embarqués, vous avez probablement faire face à cette situation assez fréquemment.
Votre solution sera probablement en couches, modulaire et découplé et ces aspects peuvent utilement être représentés et renforcé par le codage de différentes parties de la sous-système dans les différents fichiers.
Avec C, vous pouvez perdre beaucoup en faisant cela. Presque tous les toolchains fournir décent optimisation pour une seule unité de compilation, mais sont très pessimistes au sujet de n'importe quoi déclaré extern.
Si vous mettez le tout dans un source C module, vous obtenez -
Performance & code de taille de l'amélioration de la fonction d'appels sera incorporé dans de nombreux cas. Même sans l'in-lining, le compilateur a l'occasion de produire du code plus efficace.
Niveau liaison de données & la fonction de masquage.
L'évitement de l'espace de noms de la pollution et de son corollaire, vous pouvez utiliser moins de lourdeur noms.
Une compilation plus rapide & lien.
Mais vous obtenez également un désordre impie quand il s'agit de l'édition de ce fichier et que vous perdez de l'implicite de la modularité. Cela peut être surmonté par le fractionnement de la source en plusieurs fichiers et y compris ces pour produire une seule unité de compilation.
Vous avez besoin d'imposer certaines conventions pour gérer cela correctement malgré tout. Cela dépendra de vos outils dans une certaine mesure, mais certains indicateurs généraux sont -
A mis le public dans une interface séparée en-tête de fichier que vous devriez faire de toute façon.
Plus d'un .fichier c qui comprend l'ensemble de la filiale .c fichiers. Cela pourrait aussi inclure le code de l'interface publique.
Utilisez le compilateur gardes pour s'assurer que privé, en-têtes et les modules de code source ne sont pas inclus externe par des unités de compilation.
Toutes les données privées & fonctions doivent être déclarées static.
Maintenir la distinction conceptuelle entre les deux .c et .h fichiers. Il exploite les conventions existantes. La différence est que vous aurez beaucoup de statique des déclarations dans vos en-têtes.
Si votre chaîne de compilation n'impose pas une raison pour ne pas, le nom du privé fichiers de mise en œuvre .c et .h. Si on utilise les gardes, ceux-ci produisent pas de code et de n'introduire de nouveaux noms (vous pouvez vous retrouver avec les segments lors de couplage). L'énorme avantage est que d'autres outils (par exemple, IDEs) permettra de traiter ces fichiers de façon appropriée.
est-il ok? oui, il va compiler
est-il recommandé? pas de - .c fichiers à compiler .les fichiers obj, qui sont reliés entre eux après la compilation (par l'éditeur de liens) dans l'exécutable (ou bibliothèque), il n'est pas nécessaire d'inclure un .c fichier dans un autre. Ce que vous voulez probablement faire de la place est de rendre l' .h de fichier qui répertorie les fonctions/variables disponibles dans les autres .c fichier, et comprennent les .h fichier
Pas.
En fonction de votre environnement de compilation (vous ne précisez pas), vous pouvez trouver qu'il fonctionne exactement de la manière que vous voulez.
Cependant, il existe de nombreux environnements (les deux IDEs et beaucoup de main fabriqués Makefiles) qui s'attendent à compiler *.c - si cela vous arrive, vous aurez probablement jusqu'à la fin de l'éditeur de liens avec des erreurs dues à double symboles.
En règle générale, cette pratique devrait être évitée.
Si vous devez absolument #include source (et en général, il devrait être évité), utiliser un autre suffixe de fichier pour le fichier.
J'ai pensé que je devais partager une situation où mon équipe a décidé de l'inclure .c fichiers. Notre archicture grande partie se compose de modules qui sont découplées par le biais d'un message système. Ces gestionnaires de messages sont publics, et que beaucoup statique locale travailleur fonctions pour faire leur travail. Le problème est survenu lors de la tentative d'obtenir une garantie pour notre unité de test des cas, le seul moyen de l'exercice privé de la mise en œuvre du code a été indirectement par le public de l'interface des messages. Avec certains travailleurs fonctions jusqu'aux genoux dans la pile, ce qui s'est avéré être un cauchemar à atteindre une bonne couverture.
Y compris l' .c fichiers nous a donné un moyen pour atteindre le rouage de la machine, nous avons été intéressant dans les tests.
L'extension du fichier n'est pas question pour la plupart des compilateurs C, de sorte qu'il fonctionne.
Toutefois, selon votre makefile ou les paramètres de projet de la c inclus fichier peut générer un objet distinct de fichier. Lors de la liaison qui peut conduire à une double symboles définis.
Vous pouvez utiliser le compilateur gcc sous linux pour le lien c deux fichiers en une seule sortie. Supposons que vous avez deux c fichiers un est principal.c' et l'autre est le soutien.c'.
Donc la commande de lien entre ces deux est
Par ces deux fichiers seront liés à une seule sortie principale.hors
Pour exécuter la sortie de la commande sera
Si vous utilisez la fonction dans le main.c qui est déclaré à l'appui.c fichier, puis vous devez les déclarer dans le main se charge aussi de l'aide externe de stockage de classe.
Vous pouvez inclure .C ou .Fichiers CPP dans d'autres fichiers source.
En fonction de votre IDE, vous pouvez généralement éviter la double liaison en regardant le source des fichiers de propriétés que vous souhaitez être inclus, généralement par un clic droit dessus et en cliquant sur propriétés, puis décochez la case/case compilation/lien/exclure de construire ou quelle que soit l'option, il peut être. Ou vous ne pouvez pas inclure le fichier dans le projet lui-même, donc l'IDE l'habitude même de savoir qu'elle existe et que l'habitude d'essayer de le compiler. Et avec les makefiles il vous suffit juste de ne pas mettre le fichier en pour la compilation et la liaison.
EDIT: Désolé, j'ai fait une réponse au lieu de répondre sur d'autres réponses 🙁
Le langage C n'interdit pas ce genre de #inclure, mais le résultat de l'unité de traduction doit encore être valide C.
Je ne sais pas quel programme que vous utilisez avec une .chemin du fichier. Si vous utilisez quelque chose comme "faire" ou de Visual Studio, ou que ce soit, assurez-vous que vous définissez la liste des fichiers à compiler sans lequel on ne peut pas compiler de façon indépendante.
Y compris C fichier dans un autre fichier est légal, mais pas conseillé chose à faire, sauf si vous savez exactement pourquoi vous faites et ce qui sont que vous essayez d'atteindre.
Je suis presque sûr que si vous le poste ici, la raison derrière votre question, la communauté va vous en trouver un autre plus adaptée pour atteindre votre objectif (veuillez noter que le "presque", car il est possible que ce soit la solution, étant donné le contexte).
Par la façon dont j'ai raté la deuxième partie de la question. Si C fichier est inclus dans un autre fichier et dans le même temps inclus pour le projet que vous n'aurez probablement jusqu'à la fin avec double symbole de problème, pourquoi lier les objets, j'.e même fonction sera définie par deux fois (à moins qu'ils sont tous statiques).
vous devez ajouter un en-tête comme ce
remarque : les deux fichier doit placés dans un même lieu