Est-il acceptable (ou même recommandé/bonne pratique) de #include
a .c
dans un autre .c
fichier ?
Réponses
Trop de publicités?L'extension du fichier n'a pas d'importance pour la plupart des compilateurs C, donc cela fonctionnera.
Cependant, en fonction de votre makefile ou des paramètres du projet, le fichier c inclus peut générer un fichier objet séparé. Lors de la liaison, cela peut conduire à des symboles doublement définis.
Vous pouvez inclure correctement des fichiers .C ou .CPP dans d'autres fichiers sources. En fonction de votre IDE, vous pouvez généralement empêcher la double liaison en regardant les propriétés du fichier source que vous voulez inclure, généralement en faisant un clic droit dessus et en cliquant sur propriétés, et en décochant/cochant compiler/lier/exclure de la compilation ou toute autre option. Ou vous pouvez ne pas inclure le fichier dans le projet lui-même, ainsi l'IDE ne saura même pas qu'il existe et n'essaiera pas de le compiler. Et avec les makefiles, il suffit de ne pas mettre le fichier dedans pour la compilation et l'édition de liens.
EDIT : Désolé, j'en ai fait une réponse au lieu d'une réponse à d'autres réponses :(
Inclure un fichier C dans un autre fichier est légal, mais déconseillé, à moins que vous ne sachiez exactement pourquoi vous le faites et ce que vous essayez d'obtenir.
Je suis presque sûr que si vous postez ici la raison qui sous-tend votre question, la communauté vous trouvera un autre moyen plus approprié pour atteindre votre objectif (notez le "presque", car il est possible que ce soit la solution compte tenu du contexte).
Au fait, j'ai manqué la deuxième partie de la question. Si le fichier C est inclus dans un autre fichier et en même temps inclus dans le projet, vous aurez probablement un problème de duplication de symbole lors de la liaison des objets, c'est-à-dire que la même fonction sera définie deux fois (à moins qu'elle soit statique).
De nombreuses autres réponses ont plus que couvert comment vous pouvez le faire, mais pourquoi vous ne devriez probablement pas le faire dans des circonstances normales. Cela dit, je vais ajouter pourquoi je l'ai fait dans le passé.
Dans le domaine du développement embarqué, il est fréquent que le code source du fournisseur de silicium fasse partie de vos fichiers compilés. Le problème est que ces fournisseurs n'ont probablement pas les mêmes guides de style ou les mêmes paramètres standard de drapeaux d'avertissement/d'erreur que votre organisation.
Ainsi, vous pouvez créer un fichier source local qui inclut le code source du fournisseur, puis compiler ce fichier C enveloppant à la place pour supprimer tous les problèmes dans la source incluse ainsi que tous les en-têtes inclus par cette source. Par exemple :
/**
* @file vendor_wrap.c
* @brief vendor source code wrapper to prevent warnings
*/
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wnested-externs"
#include "vendor_source_code.c"
#pragma GCC diagnostic pop
Cela vous permet d'utiliser des scripts Make moins compliqués avec un ensemble standard de drapeaux et de paramètres de compilation avec des exceptions spécifiques dans le code plutôt que d'avoir des drapeaux personnalisés pour certains fichiers dans le script.
gcc main.c vendor_wrap.c -o $(CFLAGS) main.out
Le langage C n'interdit pas ce genre de #include, mais l'unité de traduction qui en résulte doit quand même être un C valide.
Je ne sais pas quel programme vous utilisez avec un fichier .prj. Si vous utilisez quelque chose comme "make" ou Visual Studio ou autre, assurez-vous simplement que vous définissez sa liste de fichiers à compiler sans celui qui ne peut pas être compilé indépendamment.