Discussion :

[salseropom]

bonjour, sur la page suivante section 7.2.1 Fichier en-tête d'un fichier source il est marqué : "Par ailleurs, il faut faire précéder la déclaration de la fonction du mot-clef extern, qui signifie que cette fonction est définie dans un autre fichier"

et il est mis en exemple :

/**********************************************************************/
/*** fichier: produit.h ***/
/*** en-tete de produit.c ***/
/**********************************************************************/

extern int produit(int, int);

pour ma part, dans mon .h, je ne mets jamais le mot clé extern. Est-ce que cela change bcp de chose de ne pas le mettre ?

Merci.

[souviron34]

ce n'est pas obligatoire, mais c'est la meilleure pratique

[Franck.H]

Est-ce que cela change bcp de chose de ne pas le mettre ?

Bin non, le prototype de la fonction étant dans un header, elle est automatiquement extern, chose tout à fait logique vu qu'il suffit d'inclure le header dans un fichier source.

[salseropom]

OK, merci de vos précisions.

Merci aussi pour les cours de programmation langage C et la FAQ Langage C

[souviron34]

j'ai tapé trop tot sur envoyer...

Non ce n'est pas obligatoire, mais c'est recommandé pour plusieurs raisons.

La première est la lisibilité et la séparation de ce qui est privé et publique.

Toute fonction à usage exclusif d'un module devrait être déclarée "static".

Toute fonction non déclarée comme "static" est utilisable à l'extérieur, qu'elle soit ou non dans un ".h", pour peu que l'utilisateur sache comment cette fonction s'appelle....

Donc, au vu des 2 phrases ci-dessus, un ".h" ne devrait donc contenir que des fonctions à usage public.

Le mot-clé extern n'est pas obligatoire, mais préféré car :

- un "include" pourrait (même si cela n'est pas recommandé) se situer n'importe où dans le code source, et par conséquent en particulier éventuellement après une définition d'une fonction locale portant le même nom. Si le mot extern n'est pas utilisé, le compilateur ne se plaindra pas, mais prendra la définition du ".h" comme une nouvelle définition de fonction (vide) qui écrasera la précédente.
Si par contre la fonction était déclarée extern, le compilateur se plaindra...

- Pour la même raison mais en sens inverse, si l'include est inclus en tête du fichier, et que l'on re-définit une fonction portant le même nom, si dans le ".h" la routine n'est pas déclarée comme extern le compilateur ne se plaindra pas, et prendra la nouvelle définition comme étant la bonne. Si elle est déclarée comme extern le compilateur se plaindra...

[Emmanuel Delahaye]

jLa première est la lisibilité et la séparation de ce qui est privé et publique.

Huh ! Les interfaces publiques sont dans le .h. Ce qui est privé (static) est dans le .c et est rarement séparé de son implémentation... Je ne vois pas ce qu'extern apporte là-dedans. La séparation est 'géographique'.

http://emmanuel-delahaye.developpez....ganiser_source
http://emmanuel-delahaye.developpez.....htm#organiser

Toute fonction à usage exclusif d'un module devrait être déclarée "static".

OK.

Toute fonction non déclarée comme "static" est utilisable à l'extérieur, qu'elle soit ou non dans un ".h", pour peu que l'utilisateur sache comment cette fonction s'appelle....

Il est d'usage (Bonne Manière) qu'elle ait un prototype séparé et qui soit placé dans un .h visible de l'implémentation (une option de gcc permet de faire un warning en cas de manquement).

Donc, au vu des 2 phrases ci-dessus, un ".h" ne devrait donc contenir que des fonctions à usage public.

Tu parles de prototypes, bien sûr...

[C99] Le cas des fonctions inline est un peu étrange, car il existe des 'static inline'...

Le mot-clé extern n'est pas obligatoire, mais préféré car :

- un "include" pourrait (même si cela n'est pas recommandé) se situer n'importe où dans le code source, et par conséquent en particulier éventuellement après une définition d'une fonction locale portant le même nom. Si le mot extern n'est pas utilisé, le compilateur ne se plaindra pas, mais prendra la définition du ".h" comme une nouvelle définition de fonction (vide) qui écrasera la précédente.
Si par contre la fonction était déclarée extern, le compilateur se plaindra...

Mmm... possible... portable ?

- Pour la même raison mais en sens inverse, si l'include est inclus en tête du fichier, et que l'on re-définit une fonction portant le même nom, si dans le ".h" la routine n'est pas déclarée comme extern le compilateur ne se plaindra pas, et prendra la nouvelle définition comme étant la bonne. Si elle est déclarée comme extern le compilateur se plaindra...

Moui, pas sur que ce soit une exigence du langage, mais plutôt une QoI (Quality of Implementation)

[souviron34]

Il est d'usage (Bonne Manière) qu'elle ait un prototype séparé et qui soit placé dans un .h visible de l'implémentation (une option de gcc permet de faire un warning en cas de manquement).

Tu parles de prototypes, bien sûr...

OUI mais c'était justement le sens de sa question d'origine...
(visiblement il avait envie de se passer des extern...)
Et TOUTE fonction même non déclarée dans le '.h", si elle n'est pas déclarée statique, peut être appelée par tout module externe, pour peu qu'on se lie avec la bonne bibliothèque..

[C99] Le cas des fonctions inline est un peu étrange, car il existe des 'static inline'...

Il me semble que ça existait aussi avant, non ?

Le mot-clé extern n'est pas obligatoire, mais préféré car :

- un "include" pourrait (même si cela n'est pas recommandé) se situer n'importe où dans le code source, et par conséquent en particulier éventuellement après une définition d'une fonction locale portant le même nom. Si le mot extern n'est pas utilisé, le compilateur ne se plaindra pas, mais prendra la définition du ".h" comme une nouvelle définition de fonction (vide) qui écrasera la précédente.
Si par contre la fonction était déclarée extern, le compilateur se plaindra...

Mmm... possible... portable ?

- Pour la même raison mais en sens inverse, si l'include est inclus en tête du fichier, et que l'on re-définit une fonction portant le même nom, si dans le ".h" la routine n'est pas déclarée comme extern le compilateur ne se plaindra pas, et prendra la nouvelle définition comme étant la bonne. Si elle est déclarée comme extern le compilateur se plaindra...

Moui, pas sur que ce soit une exigence du langage, mais plutôt une QoI (Quality of Implementation)

Ce n'est pas une exigence du tout (quoique... voir plus bas.. mais je ne connais pas les specs des compilos), mais c'est constant dans les implémentations, ne serait-ce que pour répondre aux gens qui mettent des protoypes vides en tête de leurs modules (une reminiscence de Pascal, sans doute )

Quand tu mets un proto vide en tête, quand le compilo rencontre la vraie défintion, il remplace. (suivant l'ordre de compil ou de liens)

Et donc c'est hautement dangereux, si la fonction porte le même nom qu'une qui est dans un ".h" et n'est pas déclarée extern, car elle est alors remplacée... et réciproquement...

Exemple :

faire appel à sqrt sans avoir inclus "math.h" ne provoque pas de scandale (en tout cas pas que j'ai vu), mais sort 0... D'ailleurs toutes les fonctions de maths se comprtent de la même manière (log par exemple)...

[Emmanuel Delahaye]

extern int produit(int, int);

pour ma part, dans mon .h, je ne mets jamais le mot clé extern. Est-ce que cela change bcp de chose de ne pas le mettre ?

Pour les fonctions, le mot clé extern devant un prototype a une valeur purement documentaire. On a le droit de l'omettre