Discussion :

[dré kam]

Salut!
Je viens de finir un programme qui marche normalement, mais j'ai voulu le découper en plusieurs fichiers et depuis il ne compile plus. Il me signale des définitions multiples mais l'erreur provient des fichiers du répertoire /tmp.
Après quelques recherches j'ai vu qu'il faut utiliser extern avant de déclarer les variables mais je ne comprends pas vraiment et ça ne marche toujours pas!
Pour le moment, les variables globales sont déclarées dans le header et le header est inclus dans tous les fichiers.
Merci d'avance pour vos réponses.

[LittleWhite]

Bonjour,

Pour un projet utilisant plusieurs fichiers de compilations, il est important que les fichiers d'entêtes (.h) contiennent les gardes, c'est à dire:

Code :

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

1
2
3
4
5
6
7
 
#ifndef FICHIER_H
#define FICHIER_H
 
// Les déclarations des fonctions
 
#endif

Maintenant, les variables. En fait, vous ne devriez pas avoir de variable globales (disons qu'il y a que très peu de chances que cela vous soit totalement nécessaires). Donc le plus simple serait de les éviter et de prendre de bonnes habitudes tout de suite.
Pour revenir au mot clé extern, vous pouvez lire la FAQ C.

[Obsidian]

Bonsoir,

Si tu ne nous présentes ni ton code, ni le message d'erreur, ça va être difficile d'être précis.

Je viens de finir un programme qui marche normalement, mais j'ai voulu le découper en plusieurs fichiers et depuis il ne compile plus. Il me signale des définitions multiples mais l'erreur provient des fichiers du répertoire /tmp.

Si tu vois des fichiers aux noms bizarres dans /tmp, c'est que c'est en fait le linker qui est à l'œuvre. Ça veut dire que tes fichiers compilent tous correctement individuellement, mais qu'il est impossible de les rassembler pour former l'exécutable final. Sans doute, ici, à cause de conflits.

Après quelques recherches j'ai vu qu'il faut utiliser extern avant de déclarer les variables mais je ne comprends pas vraiment et ça ne marche toujours pas! Pour le moment, les variables globales sont déclarées dans le header et le header est inclus dans tous les fichiers. Merci d'avance pour vos réponses.

1. Les variables globales, c'est mal ;
2. Sache que le compilateur C ne fait pas le distingo lui-même entre les différents types de fichiers source (*.h, *.c, etc.). Si tu inclus un fichier à un endroit donné, ce sera comme si tu avais saisi son contenu directement à cet endroit.

« extern » permet justement de dire au compilo qu'une variable existe bien mais ailleurs. Il te croira sur parole et la résolution de son adresse en mémoire sera faite à l'édition des liens. Donc, si tu as déclaré une variable globale dans un header, elle sera retrouvera instanciée dans chacun des fichiers qui l'incluent. Et, à l'édition des liens, on va se retrouver avec n variables en conflit portant toutes le même nom.

Si maintenant , tu mets « extern » partout, cela va compiler mais, au bout d'un moment, il faudra bien la créer pour de vrai, cette variable. Sinon, là encore à l'édition des liens, le linker va te dire que tu y fais référence mais qu'il ne la trouve pas.

Ce qu'il faut faire, donc, c'est la déclarer « extern » dans ton header pour que tous les fichiers puissent s'y référer, puis l'instancier dans un et un seul code *.c .

[bpy1401]

Bonjour

Voici un petit exemple qui recapitule tout cela

fichier1.c qui produit toto

Code :

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

int toto;

fichier1.h qui déclare toto pour les autres

Code :

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

1
2
3
4
5
6
7
 
#ifndef FICHIER_1
#define FICHIER_1
 
extern int toto;
 
#endif

fichier2.c qui utilise toto

Code :

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

1
2
3
4
5
6
#include "fichier1.h
 
void fonction(void)
{
   toto = 5;
}

[dré kam]

Merci beaucoup, ça marche nickel.
Cela dit je sais que c'est pas conseillé les variables globales mais là ça rend le code beaucoup plus présentable; je dois réécrire ls donc je trouve que c'est bien plus joli de mettre les options en global que de passer autant d'arguments que d'options possibles à chaque fonction.

[Obsidian]

Bonjour,

Cela dit je sais que c'est pas conseillé les variables globales mais là ça rend le code beaucoup plus présentable; je dois réécrire ls donc je trouve que c'est bien plus joli de mettre les options en global que de passer autant d'arguments que d'options possibles à chaque fonction.

Tu te trompes. Il faut que tu relises mon post car, si c'est un exercice scolaire, ton prof risque d'être assez mécontent, et ce sera à juste titre. L'objectif de l'exercice est justement de prendre d'emblée les bonnes habitudes et de ne pas céder à cette facilité.

Pour réécrire ls, tu n'as besoin que de deux fonctions : la fonction main() qui fait les inits, ressort avec le bon code d'erreur, parse éventuellement les options et ta fonction de parcours du répertoire. À aucun moment, tu n'as besoin de variables globales pour gérer tout cela, et encore moins pour passer des valeurs d'une fonction à l'autre.

Si tu ne fais que lister à plat le contenu d'un répertoire, ta fonction est purement itérative et la seule chose que tu aies besoin de lui passer est le nom du répertoire à explorer. Mieux, tu ouvres le répertoire avec opendir() depuis main(), et tu passe la ressource ouverte à l'autre fonction. Donc, un seul argument.

Si tu veux ensuite simuler le comportement de « ls -R », qui ré-entre automatiquement dans les sous-répertoires quand il en trouve, c'est à peine plus difficile : ta fonction devient récursive. Il s'agit simplement d'ouvrir à nouveau le sous-répertoire rencontré et de se rappeler soi-même en passant en paramètre le pointeur vers la structure DIR renvoyée par opendir(), exactement de la même façon que main() l'a fait pour le premier.

Mais là, pour le coup, tes variables doivent impérativement se trouver dans la pile et NE DOIVENT PAS être globales, sinon ça ne marchera pas. Et je pense que c'est ce que ton prof veut que tu fasses.

Donc oublie les globales dans ce cas précis, parce que même la facilité d'utilisation n'est plus justifiée.

[dré kam]

J'ai fait plusieurs options, dont le -R mais aussi le -l et le -d etc... (j'en ai fait 6 en tout). Tout marche normalement. Mais j'ai fait une fonction d'affichage qui doit avoir accès à tous les paramètres, et 2 fonctions de tris (par date, par nom). Donc la fonction d'affichage doit savoir si il y a l'option -l ou -d etc.... pour savoir ce qu'elle doit afficher. En gros elle doit avoir autant d'arguments que d'options possibles et il en va de même pour d'autres fonctions. C'est pour ça que j'utilise les globales.
Ceci dit est-ce que ce serait mieux de passer 8 valeurs en paramètres?

[Obsidian]

Ceci dit est-ce que ce serait mieux de passer 8 valeurs en paramètres?

Ni l'un ni l'autre. Si tu te retrouves à passer huit valeurs en paramètre, c'est que ton modèle est bancal. Lorsqu'on a vraiment besoin de passer un contexte entier à plusieurs fonctions similaires, on utilise une structure qui contient toutes les informations nécessaires et on passe un pointeur pointeur vers cette structure à ces fonctions. Donc, un seul paramètre, et ça te permet éventuellement d'utiliser plusieurs contextes, le cas échéant. Cela dit, ce n'est pas cette approche que tu dois utiliser non plus.

Si tu tries tes entrées de fichiers avant de ré-entrer dans tes sous-répertoires, ça t'empêche d'appliquer directement la récursivité mais, quelque part, c'est encore mieux parce que ça t'oblige à lire tout le contenu d'un répertoire avant de passer au suivant, ce qui te permet de ne garder qu'une seule structure DIR ouverte à la fois, et le système t'en sera reconnaissant.

Mais là encore, que ce soit pour trier ou pour afficher, à aucun moment tu n'as besoin d'une fonction à huit paramètres.

L'idée est d'en faire le maximum pendant la boucle qui te sert à parcourir les entrées du répertoire. En théorie, tu pourrais un tri insertion, par exemple, mais le plus facile au début reste le chargement d'un tableau de structures et son tri avec qsort().

De là, chaque fonction ne doit recevoir en paramètre que les arguments dont elle a besoin pour faire son propre travail. Ta fonction « affichage », par exemple, n'a besoin de recevoir qu'un pointeur vers UNE SEULE structure « dirent » pour en afficher nom de son fichier à l'écran, et son type.

[dré kam]

Ni l'un ni l'autre. Si tu te retrouves à passer huit valeurs en paramètre, c'est que ton modèle est bancal. Lorsqu'on a vraiment besoin de passer un contexte entier à plusieurs fonctions similaires, on utilise une structure qui contient toutes les informations nécessaires et on passe un pointeur pointeur vers cette structure à ces fonctions. Donc, un seul paramètre, et ça te permet éventuellement d'utiliser plusieurs contextes, le cas échéant. Cela dit, ce n'est pas cette approche que tu dois utiliser non plus.

Je trouve que ce serait très bien une structure "options" passée en paramètre. Pourquoi je ne devrais pas l'utiliser dans ce cas?

[Obsidian]

Je trouve que ce serait très bien une structure "options" passée en paramètre. Pourquoi je ne devrais pas l'utiliser dans ce cas?

Parce que c'est le principe même de contexte global qui pose problème : il n'y a rien dans ton projet qui nécessite une telle approche et si tu te retrouves contraint d'y recourir, c'est qu'il y a quelque chose de mal conçu en amont.

[dré kam]

D'accord je vais tenter d'améliorer l'algorithme. Merci pour votre aide!