Salut à tous, alors voila je me suis remis au C depuis peu et je m'intéresse actuellement à la programmation modulaire.

J'ai réalisé un petit programme qui compilait et marchait parfaitement, et j'ai voulu décomposer celui-ci en 4 fichiers (main.c, main.h, fichier.c, fichier.h) afin d'expérimenter le truc.

Voici un aperçu du contenu de mes 4 fichiers :

main.c :

1. include "main.h"

+ fonction main

main.h :

1. include LIB
2. include "fichier.c"

fichier.c :

1. include fichier.h

+ corps de toutes mes fonctions

fichier.h :
prototypes de toutes mes fonctions

J'ai également ajouté les directives de pré-processeur qui permettent de ne pas avoir plusieurs inclusions du même fichier. ("ifndef...")

Tous ces fichiers se trouvent dans le même répertoire, et pourtant, avec Dev C++ comme avec Code::Blocks, le compilateur trouve des définitions multiples de mes fonctions.

J'ai testé pas mal de trucs, mais rien n'y faisait, jusqu'au moment ou j'ai décidé d'enlever tous les #includes (hormis les libs), et la, miracle ça marche, sous Dev C++, comme sous Code::Blocks !

Alors, si quelqu'un pouvait m'expliquer pourquoi ? Ces deux compilateurs ajoutent-ils directement les lignes lorsqu'on inclut les fichiers ans un projet ? Ai-je fait n'importe quoi ? Bref, merci de m'éclairer sur le sujet.

Bonjour,

Règle d'or : ne ***JAMAIS*** inclure un fichier .c !

Les fichiers .h contiennent les descriptions (on parle aussi de signature) de ce que permet de faire le fichier .c correspondant. Quans tu fais un nouveau fichier, que ce soit une signature (un .h) ou du code (un .c), tu t'arranges pour inclure juste les signatures dont tu as besoin.

Sinon, je ne sais pas comment les IDEs pour windows gèrent leur sauces, mais normalement, au niveau des includes, ça donne :

main.c :
-> main.h
-> fichier.h

fichier.c :
-> fichier.h

fichier.h :
-> pas d'include

main.h :
-> include de fichier.h seulement si celui-ci contient des définitions (typdef/struct) de types qui apparaissent dans les déclarations faites dans main.h

À noter que les fichiers .h sont facultatifs. Le compilateur ne compile normalement que des .c. Et je soupsonne Code::Blocks et Dev-C++ de compiler bêtement chacun des .c puis d'essayer d'assembler les fichiers objets obtenus dans un certains ordre (le bon ordre est "fichier.o main.o" et apparemment c'est l'ordre utilisé, lucky you).

Ah bah d'accord !
Merci à toi pour toutes ces explications très claires ! ^^

Il me semble qu'en C, il n'y a pas de bon ordre pour l'inclusion des fichers .o dans les cas simples (si chaque fonction n'apparait qu'une fois, il n'y a pas besoin qu'elle soit implémenté avant d'être utilisé).

Par contre, dans les cas complexes, je crois que le bon ordre est l'ordre inverse, i.e. que le l'édition de lien se fait lorsque tout les fichiers ont été lu et donc que c'est le dernier qui gagne. Donc il faut commencer par main.o et finir par fichier.o pour que les fonctions de fichier.o qui sont utilisé par main.o ne soit pas remplacé par d'autre (bon, ici évidemment, ça n'arrivera pas).

chris@tarsonis:~/Temp/toto% ls
add.c add.h main.c
chris@tarsonis:~/Temp/toto% cat add.h
int add(int, int);
chris@tarsonis:~/Temp/toto% cat add.c
int add(int a, int b)
{
return a+b;
}
chris@tarsonis:~/Temp/toto% cat main.c

1. include "add.h"

int main(int argc, char *argv[])
{
add(2, 3);
return 0;
}
chris@tarsonis:~/Temp/toto% gcc -c add.c
chris@tarsonis:~/Temp/toto% gcc -c main.c
chris@tarsonis:~/Temp/toto% gcc main.o add.o -o main
chris@tarsonis:~/Temp/toto% gcc add.o main.o -o main2
chris@tarsonis:~/Temp/toto%

ha oui, effectivement.
C'est ocaml qui m'a traumatisé avec l'ordre des .cmo en fait. ^^

Il y a quelquechose comme ca en effet avec les linkers, mais je pense que c'est avec les libs. Extrait de man ld au sujet de l'option -l

The linker will search an archive only once, at the location where it is specified on the
command line. If the archive defines a symbol which was undefined in some object which
appeared before the archive on the command line, the linker will include the appropriate
file(s) from the archive. However, an undefined symbol in an object appearing later on
the command line will not cause the linker to search the archive again.

En tout cas, si je donne à manger à ld deux fichiers objets définissant le même "symbole", il m'envoie paître.

Ça ajouté à ce que tu dis godrik, ça implique qu'on se fiche complètement de l'ordre.

"C'est ocaml qui m'a traumatisé avec l'ordre des .cmo en fait. ^^ "

C'est comme ça que je m'en souviens : en C il faut faire le contraire de ce qu'il faut faire en caml. Sauf qu'il m'en manquait un bout manifestement.

Héhé.
C'est d'ailleurs très logique vu les approches de ces deux langages.