Discussion :

[denispir]

Bonjour,

Je commence à avoir besoin de modulariser et ai un petit souci sur la méthode pour compiler.

D'abord, quelle est la logique pour répartir le code entre fichiers .c et .h? Je croyais que les .h servaient juste à déclarer l'interface d'un module (ce qui est exporté), mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h ! Ce qui montre que mes présuppositions sont fausses...

Ensuite, par exemple à propos d'un module "toolkit" que j'incluerais partout, malgré l'usage d'un .h et son inclusion, la phase de lien m'envoie des erreurs dès que j'utilise une fonction définie en fait dans le fichier .c (mais bien déclarée dans le .h avec tout son typage de paramètres et de retour). Est-ce que C ou les compilateurs (gcc) ne font pas le lien implicite entre fichiers .c et .h correspondants? Sinon, comment faire moi-même ce lien pour qu'ils "comprennent" (sic)?

Enfin, comment inclure des fichiers qui ne sont pas dans le même répertoire, mais par exemple dans un répertoire au-dessus, parallèle, ou tout autre sous-répertoire dans le super-répertoire de mon projet?

Merci,
Denis

[Bousk]

Bonjour,

je suppose que tu travailles avec un IDE.
Qu'entends-tu par modules ? S'agit-il de module à part entière (header, lib) ou juste de header et .c d'un même projet ?
Dans le premier cas, il faut inclure le header correspondant, afin que le fichier connaisse les types, prototypes utilisables, et correctement linker la lib.
Dans le second cas, il faut... compiler le fichier, éventuellement inclure des header nécessaires, et inclure le header quand nécessaire par la suite, le fichier étant compilé avec le reste du programme.

mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h !

Oui un .h peut contenir du code.
Qu'y a-t-il de choquant à ça ?
Oui un .c inclut généralement (tout le temps ?) son propre .h, ne serait-ce que pour inclure les structures adéquates, et connaître tous les prototypes.

Regarde comment fonctionne la compilation, en particulier le préprocesseur et la directive include.
include insère le contenu du fichier. Donc du code dans le .h, ça ne dérange en rien. (attention aux erreurs "multiple définition")

Ensuite, par exemple à propos d'un module "toolkit" que j'incluerais partout, malgré l'usage d'un .h et son inclusion, la phase de lien m'envoie des erreurs dès que j'utilise une fonction définie en fait dans le fichier .c (mais bien déclarée dans le .h avec tout son typage de paramètres et de retour). Est-ce que C ou les compilateurs (gcc) ne font pas le lien implicite entre fichiers .c et .h correspondants? Sinon, comment faire moi-même ce lien pour qu'ils "comprennent" (sic)?

Le C, contrairement à certains langages type JAVA a une particularité : il ne cache rien.
Ton programme fait exactement ce qui est écrit. Aucun lien implicite, aucune inclusion cachée, rien.
Si la phase de lien échoue, tu as très certainement oublié de lier le .lib (.a) correspondant. Dans le cas d'une lib externe.
S'il s'agit d'une lib interne, tu as dû oublier les dépendances, ou tout simplement d'implémenter la fonction, voire d'indiquer au compilateur de compiler le fichier source qui implémente la méthode.

Enfin, comment inclure des fichiers qui ne sont pas dans le même répertoire, mais par exemple dans un répertoire au-dessus, parallèle, ou tout autre sous-répertoire dans le super-répertoire de mon projet?

Dans un IDE, tu peux aisément définir des include_path, tu peux réaliser le chemin relatif à un des include_path pour inclure le fichier.
Tu peux aussi réaliser le chemin relatif au fichier courant.
Un include n'est pas limité à un simple non de fichier (#include "header.h"), il s'agit d'un chemin, donc tout ce qu'on connait sur les chemins est utilisable (#include "../../dossier1/headder.h")

La majorité de tes questions trouveront réponse dans un cours qui traite de la chaîne de compilation. Il s'agit en général d'un des premier cours que l'on suit lorsqu'on suit un cursus pour apprendre le C.

[bpy1401]

Bonjour à tous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h !

un .h est un fichier d'inclusion, il peut mais ne doit pas contenir du code. Il est la juste pour déclarer des objets utilisables pour d'autre modules.

Et la on va me dire: c'est quoi un module:

Un module permet de réaliser une fonctionnalité. Par exemple, dans du code embarque, un module pourras gérer une liaison série, une second module pour le timer, ou tout simplement une fonctionnalité applicative.

Le .h d'un module permet aux autre modules de connaitre les interfaces de ce module. En aucun cas, on doit y mettre du code. Si par exemple, ton .h est inclus par plusieurs modules différents, ton code sera dupliqué et tu va recevoir une rafale de messages d'injure.

Oui, un module C doit contenir son .h. La raison: Cela permet de vérifier que ton .h est cohérent avec ton C. Si tu as une déclaration de fonctions dans le .h avec un nombre de paramètres différent de ce que tu as dans un .c , le fait d'inclure le .h dans le .c va générer des messages d'erreurs.

Tout logiciel C dans l'industrie est modulaire. Tu es sur la bonne voie
A+

[denispir]

Bonjour à tous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mais non seulement il semble qu'un .h puisse contenir du "vrai code", mais je suis tombé sur des exemples de .c qui importent (ou plutôt incluent) leur propre .h !

[...]
Le .h d'un module permet aux autre modules de connaitre les interfaces de ce module. En aucun cas, on doit y mettre du code. Si par exemple, ton .h est inclus par plusieurs modules différents, ton code sera dupliqué et tu va recevoir une rafale de messages d'injure.

D'accord, c'est comme ça que je comprenais les choses (avant de voir des contre-exemples ;-)

Oui, un module C doit contenir son .h. La raison: Cela permet de vérifier que ton .h est cohérent avec ton C. Si tu as une déclaration de fonctions dans le .h avec un nombre de paramètres différent de ce que tu as dans un .c , le fait d'inclure le .h dans le .c va générer des messages d'erreurs.

Pour que cet sorte d'auto-contrôle fonctionne, en plus des définitions de choses déclarées mais non définies dans le .h (disons les fonctions), ne faut-il pas aussi re-coder dans le .c les éléments comme constantes ou types (pour lesquels il n'y a peut-être pas vraiment de distinction déclaration / définition qui fasse sens) ?

Je vais donc faire ainsi: pour chaque module (au sens courant du terme en programmation, pas seulement C) exporter toutes les déclarations dans le .h ; l'inclure et coder les définitions dans le .c. Et si c'est utile, je réintroduis les constantes et types dans le .c pour auto-contrôle.

Ca ne m'explique toujours pas pourquoi je n'arrive pas à inclure mon toolkit (un module avec des petits utilitaires). En fait, il est bien programmé comme indiqué juste ci-dessus: un .h avec les déclas, un .c qui donne les defs. Les modules qui l'utilisent incluent le .h avec "#include "toolkit.h" (il est placé dans le même dossier pour ces essais -- un problème à la fois); est-ce que ce n'est pas suffisant? Qu'est-ce que je ne comprends pas? En fait, il me semble que je procède exactement comme avec les modules de la stdlib... donc ça devrait marcher (?).

Denis

[gerald3d]

Comme nous n'avons pas les messages d'erreur que tu obtiens nous sommes obligés de supposer.

Lorsque tu crées un "module", c'est à dire un .h avec .c il faut interdire la déclaration multiples de ces mêmes fonctions. Pour faire cela il faut inclure toutes tes déclarations dans le .h entre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#ifndef MA_BIBLIO
#define MA_BIBLIO
/* À partir d'ici on trouve les déclarations des structures et prototypes. */
...
#endif

[denispir]

Lorsque tu crées un "module", c'est à dire un .h avec .c il faut interdire la déclaration multiples de ces mêmes fonctions. Pour faire cela il faut inclure toutes tes déclarations dans le .h entre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
#ifndef MA_BIBLIO
#define MA_BIBLIO
/* À partir d'ici on trouve les déclarations des structures et prototypes. */
...
#endif

Oui, c'est bien ce que je fais (j'ai vu ce schéma dans d'autres fichiers). Voici la structure de toolkit.h:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
#ifndef H_TOOLKIT
#define H_TOOLKIT
 
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <assert.h>
[...]
/* common output funcs
*/
void line (void) ;
void write (char * str) ;
void end_test () ;
[...]
#endif

Mais c'est pas là mon problème: voir ci-dessous.

Comme nous n'avons pas les messages d'erreur que tu obtiens nous sommes obligés de supposer.

Excusez-moi, j'ai été trop implicite. Voici:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
gcc -Wall -o "Text" "Text.c" (in directory: /home/spir/prog/C)
Compilation failed.
/tmp/ccKIinM3.o: In function `test_creation':
Text.c:(.text+0x9fb): undefined reference to `line'
Text.c:(.text+0xa00): undefined reference to `end_test'
[... et bis repetita plusieurs fois ...]

Visiblement à l'édition de liens, il ne trouve pas certaines fonctions (des utilitaires: line, end_test, ...). Dans le fichier que je compile là, il y a bien "#include "toolkit.h" (avant l'usage desdites fonctions). Les fonctions en question sont déclarées dans toolkit.h --comme montré ci-dessus-- et définies dans toolkit.c (qui lui-même inclut maintenant toolkit.h et compile sans problème).

Denis