Problème compilation séparée

Version imprimable

12/05/2018, 14h03
exe2bin

Problème compilation séparée

Bonjour à tous ;
Je n'y arriverait jamais avec la compilation séparée ....
J'ai un gros fichier (+500 lignes) et ça commence à être pesant de s'y retrouver alors je me suis dit : " y a qu'a fragmenter en plusieurs fichier !!"
Pas mal me direz-vous; surtout que je l'ai déjà fait mais voilà : en ce qui concerne les fonctions c'est relativement aisé :
un fichier.h avec les signatures puis le fichier.c qui va avec ; on inclut le fichier.h dans tout fichier.c qui veut utiliser les fonctions et basta !
Mais ce que je ne suis jamais parvenu à faire c'est gérer les variables globales ?!
Comment faire pour signifier au fonctions qui s'en servent que celles-ci sont définies ailleurs (le mot clé extern ne suffit apparement pas) ,où et comment
procéder ???
C'est un aspect du C qui me gonfle grave !!!

Bonjour

T'inquiète pas, on va t'expliquer ça bien :chin:

Quand tu compiles un source, tu dois déclarer les variables que le source va utiliser. "Déclarer" signifie "indiquer leur existence". Quand ensuite tu veux créer l'exécutable, tu dois "définir" les variables, c'est à dire "les créer en mémoire" (si tu regardes mes posts en détails, tu verras que je fais très attention à l'emploi de ces deux verbes chaque fois que je parle de variables).
Généralement, la définition englobe aussi la déclaration. Surtout quand tu n'as qu'un seul source et que tu compiles et crées l'exécutable d'un coup. Mais dans le cas de plusieurs sources, alors il faut déclarer les variables dans chaque source qui va l'utiliser mais la définir une seule et unique fois.

La déclaration se fait via le mot clef extern qui signifie grosso-modo pour le compilo "considère qu'elle existe, t'inquiète pas elle sera définie plus tard". Donc fatalement à un endroit il faut quand-même la définir donc la déclarer sans mettre "extern". Mais il ne faut le faire que dans un seul source sinon il y aura conflit lors de l'édition de liens.

Bon moi je n'utilise pas de globales. Mais si je devais en mettre, alors je la définirais dans le source qui contient le main et la déclarerais en extern dans les autres.

Exemple
fichier "main.c"
Code:

1 2 3 4 5 int glob; int main() { glob=123; affiche(); }
Fichier "affiche.c"
Code:

1 2 3 4 extern int glob; void affiche() { printf("glob=%d\n", glob); }
A noter: les programmeurs n'aiment pas les globales principalement parce que si la variable est accidentellement modifiée, il devient difficile de déterminer qui l'a modifiée. Une astuce permettant "d'aider" à la détection est de redéclarer dans la fonction les variables globales utilisées par la fonction.

Exemple
fichier "main.c"
Code:

1 2 3 4 5 6 int glob; int main() { extern int glob; // Comme ça, les autres lecteurs savent que cette fonction utilise la variable globale "glob" glob=123; affiche(); }
Fichier "affiche.c"
Code:

1 2 3 4 5 6 7 8 9 10 extern int glob; void affiche() { extern int glob; // Pareil printf("glob=%d\n", glob); } void toto() { // Cette fonction n'utilise pas "glob", je ne la déclare donc pas ici ... autre_chose_mais_sans_utiliser_glob... }

13/05/2018, 10h19
exe2bin

Merci de ta patience mais j'ai 2 questions (au moins) :

1) est ce cela marche aussi pour les déclarations de structures et à fortiori pour les tableaux (pour lesquels on doit déclarer la taille) ?

2) peut on grouper toutes les déclarations (extern donc) dans un fichier.h puis inclure ce fichier dans tout.c qui l'utilise ?
13/05/2018, 12h33
Sve@r
Citation:

Envoyé par exe2bin

1) est ce cela marche aussi pour les déclarations de structures et à fortiori pour les tableaux (pour lesquels on doit déclarer la taille) ?

On n'applique le mot clef extern que pour les variables. Donc pour déclarer une structure ou un type (donc sans y mettre immédiatement de variable style typedef struct s_monType {...} t_monType) alors non.
Mais pour déclarer ensuite des variables de type "struct s_monType" ou "tableau" ou "t_monType" oui ça fonctionne pareil.

Citation:

Envoyé par exe2bin

2) peut on grouper toutes les déclarations (extern donc) dans un fichier.h puis inclure ce fichier dans tout.c qui l'utilise ?

Oui. On peut même faire un truc universel grace à l'inclusion conditionnelle
Exemple
Fichier "glob.h"
Code:

1 2 3 4 5 6 7 #ifndef __MAIN__ #define EXTERN extern #else // __MAIN__ #define EXTERN #endif // __MAIN__ EXTERN int glob;
Fichier "main.c"
Code:

1 2 3 4 5 6 7 #define __MAIN__ #include "glob.h" int main() { glob=123; affiche(); }
Fichier "affiche.c"
Code:

1 2 3 4 5 #include "glob.h" void affiche() { printf("glob=%d\n", glob); }
Lors de l'inclusion de "glob.h" dans le main.c, comme la macro __MAIN__ est définie, alors le mot "EXTERN" étant défini à rien n'aura aucun effet et le compilateur verra int glob. En revanche, dans les autres, comme elle n'est pas définie, le compilo verra extern int glob.
13/05/2018, 15h07
Bktero

Au-delà des considérations techniques de réussir à faire compiler ton programme, je te mets en garde (comme Svear l'a deja fait) sur le simple fait d'utiliser des variables globales. C'est pratique dans de petits programmes mais des que tu vas arriver sur des projets un peu plus gros ou si tu souhaites réutiliser des bouts de ton code dans un nouveau projet, tu verras vite que les variables globales sont une plaie... J'avais écrit un article à ce sujet https://gradot.wordpress.com/2014/07...globales-en-c/ mais Google regorge d'autres articles qui abondent dans le même sens. Sans tomber dans l'extrémisme, penses-y ! Et souvent ce n'est pas compliqué ;)
13/05/2018, 15h08
exe2bin
C'est vraiment très compliqué pour moi ....

alors que tout semblait réglé en ce qui concerne les déclarations de fonctions j'obtiens maintenant des messages style :
Code:

1 2 3 4 duplicate symbol _g_jeu in: /var/folders/bv/g3fz_2_54zz50nwkvr1y1gz00000gq/T/ginRummyV5-d75564.o /var/folders/bv/g3fz_2_54zz50nwkvr1y1gz00000gq/T/void(void)-d5c2f6.o
concernant plusieurs de mes variables globales ?!
13/05/2018, 15h21
Sve@r
Citation:
Envoyé par exe2bin

alors que tout semblait réglé en ce qui concerne les déclarations de fonctions j'obtiens maintenant des messages style :

Code:

1 2 3 4 duplicate symbol _g_jeu in: /var/folders/bv/g3fz_2_54zz50nwkvr1y1gz00000gq/T/ginRummyV5-d75564.o /var/folders/bv/g3fz_2_54zz50nwkvr1y1gz00000gq/T/void(void)-d5c2f6.o

concernant plusieurs de mes variables globales ?!
Sans le source complet de ton ginRummy ça semble compliqué de bien t'aider mais à priori il semblerait que ta variable "g_jeu" ait été définie (attention au sens de ce verbe) deux fois. C'est à dire que par deux fois (on va présumer qu'il s'agit de deux sources différents) tu l'as présentée au compilateur sans mettre le mot "extern" devant.
Donc la compilation des .c en .o s'est faite sans problème mais à l'édition de liens, le linker avait deux références à deux variables distinctes portant le même nom => duplicate symbol.
13/05/2018, 20h40
foetus

Pour éviter des duplications, je ne ferai pas comme Sve@r et son exemple :whistle:

Dans les entêtes (fichier .h), aucune définition de variables, que des déclarations (typedef, extern, interface, ...)
Et dans les sources (fichier .c), tu mets que les définitions et les #include
13/05/2018, 22h25
Sve@r

Citation:

Envoyé par foetus

Pour éviter des duplications, je ne ferais pas comme Sve@r et son exemple :whistle:

Tu auras bien noté que cet exemple (je pense que tu veux parler du second) était un exemple destiné à illustrer la question de exe2bin :whistle:

Ceci dit, je l'ai testé quand je l'ai posté et il fonctionne sans problème de duplication...

Citation:

Envoyé par foetus

Dans les entêtes (fichier .h), aucune définition de variables, que des déclarations (typedef, extern, interface, ...)
Et dans les sources (fichier .c), tu mets que les définitions et les #include

Exactement comme mon premier exemple :whistle: :whistle:
14/05/2018, 00h04
foetus

Citation:

Envoyé par Sve@r

Ceci dit, je l'ai testé quand je l'ai posté et il fonctionne sans problème de duplication...

Il faudrait justement l'inverser :mrgreen: parce sans le #define __MAIN__ tu crées une variable. Il faudrait au contraire faire des extern et obliger le #define pour créer cette variable.

D'autant plus, et en plus c'est la limite de cette méthode, dans l'imbrication des inclusions, 1 fois que __MAIN__ est définie, c'est répercuté de "proche en proche"

Bon, nous maîtrisons le C et on sait gérer les inclusions, les #define / #undef mais ce n'est pas le cas de exe2bin

Édit: :wow: Ouais effectivement j'ai lu trop vite et loupé le n (c'est 1 #ifndef) :wow:
14/05/2018, 15h04
Sve@r

Citation:

Envoyé par foetus

Il faudrait justement l'inverser :mrgreen: parce sans le #define __MAIN__ tu crées une variable. Il faudrait au contraire faire des extern et obliger le #define pour créer cette variable.

Ben c'est bien ce que je fais... Je définis EXTERN à extern si "__MAIN__" n'est pas défini (le ifndef __MAIN__ du début). Donc il faut explicitement demander un #define __MAIN__ pour avoir la variable.
Ou alors j'ai pas pigé ta phrase :koi:

Citation:

Envoyé par foetus

D'autant plus, et en plus c'est la limite de cette méthode, dans l'imbrication des inclusions, 1 fois que __MAIN__ est définie, c'est répercuté de "proche en proche"

Ouais, là c'est vrai. On peut rajouter un #undef __MAIN__ dans le cas où il passe par le branchement "__MAIN__ est défini" (bricolo et bricolette sont dans un bateau...)

Citation:

Envoyé par foetus

Bon, nous maîtrisons le C et on sait gérer les inclusions, les #define / #undef mais ce n'est pas le cas de exe2bin

Ah ben j'ai pas dit non plus que c'était le must. C'est une solution qui répond à sa seconde question pour regrouper toutes les globales de façon unique dans un ".h" qu'on pourra importer de partout mais effectivement (j'aurais dû le préciser) c'est pas top classe. Bktero le dit aussi dans son article wordpress. Sauf à de très rares exceptions (liées généralement aux fonctions qui viennent intercepter des signaux et qui n'acceptent pas de paramètre) on peut éviter les globales...

@exe2bin
... surtout que de façon assez générales, on utilise des globales par facilité. Par exemple on veut gérer un jeu, avec sa table, ses joueurs ses cartes, etc. Tout ça se répercute dans 300 variables qu'on a la flemme de passer de fonctions en fonctions (300 paramètres à chaque fois) donc on se dit "bon ben puisque ça concerne mon jeu et que toutes mes fonctions en ont besoin je les mets en globales".
Ca se tient comme raisonnement... mais les puristes n'aiment pas trop. Surtout qu'il y a d'autres solutions tout aussi efficaces et tout aussi simples mais plus respectueuses de la philosophie dont la première est la structure. En regroupant tous ses paramètres de jeu dans une structure "s_jeu" et en déclarant dans le main une variable struct s_jeu jeu, il suffit alors de passer "jeu" (ou son adresse ce qui est plus rapide) pour que toutes les fonctions qui la reçoivent héritent de son contenu. Ainsi avec un seul paramètre on peut faire passer 300/3000/30000 informations d'un coup. C'est d'ailleurs le premier pas vers la méthodologie "objet"...
15/05/2018, 09h23
exe2bin

Citation:

Envoyé par Sve@r

... surtout que de façon assez générales, on utilise des globales par facilité. Par exemple on veut gérer un jeu, avec sa table, ses joueurs ses cartes, etc. Tout ça se répercute dans 300 variables qu'on a la flemme de passer de fonctions en fonctions (300 paramètres à chaque fois) donc on se dit "bon ben puisque ça concerne mon jeu et que toutes mes fonctions en ont besoin je les mets en globales".

C'est exactement ça !
Et d'ailleurs c'est à cela qu'elles servent les variables globales ,non !

Citation:

Envoyé par Sve@r

En regroupant tous ses paramètres de jeu dans une structure "s_jeu" et en déclarant dans le main une variable struct s_jeu jeu, il suffit alors de passer "jeu" (ou son adresse ce qui est plus rapide) pour que toutes les fonctions qui la reçoivent héritent de son contenu. Ainsi avec un seul paramètre on peut faire passer 300/3000/30000 informations d'un coup. C'est d'ailleurs le premier pas vers la méthodologie "objet"...

Je m'en vais essayer cela ...
J'imagine que j'aurais dû coder en C++ ou java ou python ....
15/05/2018, 09h45
Bktero

C'est moi où on peut faire des structures en C ? :aie:

C'est moi où en C++ tu aurais eu les mêmes problèmes ? :arrow:
15/05/2018, 10h37
Sve@r
Citation:

Envoyé par exe2bin

C'est exactement ça !

Ben quand je vois un fichier nommé "ginRummy" c'est pas difficile d'imaginer ce dont il s'agit et d'extrapoler les premiers problèmes rencontrés... ;)

Citation:

Envoyé par exe2bin

Et d'ailleurs c'est à cela qu'elles servent les variables globales ,non !

Bizarre car tu formules ça comme une question (c'est généralement le cas quand on rajoute "non" ou "n'est-ce pas" en fin de phrase) mais tu as mis un point d'exclamation...

Je n'arrive pas à trouver sur le net de traité sur le but d'une globale mais je trouve plein de discussions sur le fait qu'on puisse ou ne puisse pas les utiliser. Ici https://fr.wikipedia.org/wiki/Variable_globale un résumé assez clair de la question, des avantages et des inconvénients. En tout cas je ne suis pas certain qu'elles servent à s'éviter de devoir travailler la conception...

Citation:

Envoyé par exe2bin

J'imagine que j'aurais dû coder en C++ ou java ou python ....

En C++ tu aurais eu les mêmes soucis (comment transmettre plein d'informations de fonctions en fonctions avec facilité) mais tu aurais eu l'avantage de l'objet (pouvoir créer des concepts qui intègrent à la fois des données pour le quantifier et à la fois les actions pour le faire évoluer, actions ayant alors directement accès aux données de l'objet ; alors qu'en C tu n'as que les données et les actions doivent s'écrire en dehors et les actions qui doivent avoir accès aux données de l'objet doivent alors recevoir cet objet en paramètre).
En Python c'est un peu plus complexe: toute variable dite "globale" n'est connue que dans le source qui l'a créée (ton premier post parlait de découper un gros source en plein de petits distincts) mais tu peux importer un source dans un autre et donc accéder ainsi aux variables du source importé. Toutefois une fonction doit spécifier explicitement qu'elle va utiliser une globale si elle veut pouvoir la modifier sinon elle y a quand-même accès mais en lecture seule. De plus, dans ce cas, si on écrit une seule instruction faisant référence à la globale (comme un print par exemple) on n'a alors plus le droit de définir une variable portant le même nom (dans ce cas Python le prend comme une tentative de modification de la globale). Donc d'autres contraintes à prendre en compte. Sinon Python intègre aussi la notion d'objet. De plus c'est vrai que Python offre une syntaxe permettant d'aller beaucoup plus vite qu'en C.
Java connais pas (enfin pas assez pour en parler).

Mais en fait, je pense que tu fais face à deux soucis
1. apprendre à utiliser le mot-clef extern
2. utiliser cette science pour ton projet
A mon avis, tu devrais commencer par de petits tests pour bien maitriser. Reprends mon premier exemple, compile-le. Ensuite rajoute extern là où il n'y est pas (donc dans "main.c") et recompile, et regarde ce que ça donne. Ensuite supprime extern partout où il y est et recompile.
Une fois que tu auras compris ce qui se passe dans les 3 cas, tu pourras alors (j'espère) étendre ta connaissance toute neuve à 3 sources, puis rapidement tu pourras gérer un projet.
Et enfin quand tu sauras bien maitriser les globales, c'est là qu'on te redira alors qu'il faut les éviter.:mrgreen: