Bonjour,
j'ai 3 fichier en C
fich1.c
fich2.c
main.c
j'utilise codeBlocks
quand je compile au lieu de passer par le main qui appelle fich1 et fich2
le compilateur débute par compiler fich1 et fich2
Bonjour,
j'ai 3 fichier en C
fich1.c
fich2.c
main.c
j'utilise codeBlocks
quand je compile au lieu de passer par le main qui appelle fich1 et fich2
le compilateur débute par compiler fich1 et fich2
Je ne vois pas où est le problème. On peut compiler n'importe quel fichier sans se soucier des autres de fichiers du projet. La commande pour compiler un fichier dans C::B est Build > Compile Current File (Ctrl + Shift + F9).
Salut,
Euh, quoi de plus normal si tu lui demande de compiler l'intégralité du projet ?
Pour produire ton exécutable, le compilateur a besoin de tous les fichiers objet.
En effet pour réaliser la dernière étape de la compilation (l'édition des liens) il faut les trois fichiers objet correspondant à tes trois fichiers source.
En gros, la dernière directive de compilation pour obtenir ton exécutable est:
main.o, fichier1.o et fichier2.o sont des fichiers nécessaires à la création de ton exécutable, c'est ce que l'on appelle des dépendances.
Code : Sélectionner tout - Visualiser dans une fenêtre à part gcc -o nom_exécutable main.o fichier1.o fichier2.o (+ des options, généralement -Wall et -pedantic)
Pour obtenir des fichiers, par exemple main.o il faut faire:Il faut donc compiler ces trois fichiers, peut importe l'ordre du moment que l'on obtienne les fichiers objet. Codeblocks a choisi de commencer par ton main
Code : Sélectionner tout - Visualiser dans une fenêtre à part gcc -o main.o main.c (+options)
Je te conseille de compiler par toi même ton projet en ligne de commande, tu comprendras mieuxL'idéal étant d'utiliser un makefile c'est facile et rapide.
le problème est:
fich1 j'utilise :quand le fich2 se compile :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 typedef struct{ double R; double I; }complex;
il ne reconnais pas "complex"
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 complex Complex_canal(double x) { complex A; .....
error: syntax error before "Complex_canal"|
error: `complex' undeclared (first use in this function)|
Et…*qu'est-ce qui t'ennuie ?
Le compilateur ne va pas suivre lui-même le fil de l'exécution d'un programme. Il va compiler ce qu'il trouve dans chaque fichier vers un fichier objet. L'usage veut qu'il y ait un fichier objet par fichier *.c, mais ce n'est pas une obligation technique.
Chacun de ces fichiers objets va en fait contenir la forme compilée de ce que le compilateur a trouvé en examinant tes fichiers sources. Notamment les fonctions, pour lesquelles on retrouvera d'un côté le code compilé et, de l'autre, une table de correspondance entre les noms de fonctions et leur point d'entrée dans le code compilé. À charge à quiconque, à ce stade, d'utiliser ces ressources comme bon lui semble.
Cette dernière tâche, en fait, va revenir à l'éditeur de liens (linker), dont le travail consiste à retrouver dans les différents fichiers objets les ressources appelées par d'autres, mais il n'y a plus de notion de hiérarchie à ce stade.
Enfin, le compilateur peut demander à l'éditeur de liens de générer un fichier exécutable en particulier (ce qui est pratiquement toujours le cas). Pour cela, il va ajouter au fichier final tous les headers nécessaires à l'intégration dans le système d'exploitation du fichier compilé ET va rechercher une fonction nommée « main » pour s'en servir de point d'entrée dans ton programme.
Donc, l'ordre dans lequel les différents fichiers objets sont compilés dans la première phase importe peu. À dire vrai, ils pourraient même l'avoir été par un autre compilateur. C'est spécialement vrai lorsque tu utilises des bibliothèques statiques ou des morceaux de programmes écrits dans d'autres langages.
EDIT : (j'ai oublié de recharger la page avant de poster, désolé !)
Et bien, c'est justement pour cela que l'on utilise des fichiers « *.h » !il ne reconnais pas "complex"
error: syntax error before "Complex_canal"|
error: `complex' undeclared (first use in this function)|
Ces fichiers sont censés contenir les définitions de structures, les déclarations de variables externes, et les prototypes de fonctions. Bref : tout ce qui est déclaré ou défini mais pas encore instancié.
Un tel fichier va donc expliquer comment une fonction doit être appelée sans qu'il dispose du code : du moment que le nom de la fonction, ses arguments et leurs types sont précisés, c'est tout ce qu'il faut au compilateur pour produire du code exécutable qui sera lié ensuite aux autres fichiers.
Il faut donc que tu écrives un fichier *.h pour chaque fichier *.c, dans lequels tu n'écriras que les prototypes de tes fonctions. Il faudra faire ensuite un #include "fichier.h" au début de chaque fichier *.c qui y fait appel.
Partager