Discussion :

[run(F) jkldc]

Bonjour,

soit le code suivant:

Code :

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

1
2
3
4
5
6
7
8
9
 
#define FileNumber 3;
 
 
int FileNumber () {
 
	return FileNumber;
 
}

dans 3.c
et respectivement le même code pour 1.c et 2.c

si maintenant dans 3.c j'ecris:

Code :

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

1
2
3
4
5
6
 
int FileNumberSum (FILE F1, FILE F2) {
 
	return // la somme de FileNumber de chaque .c;
 
}

comment accéder à la valeur FileNumber propre à chaque .c ou appeler la fonction FileNumber () de chaque .c ? Si toutefois c'est possible sans espaces de noms. Ca a une odeur de très mauvaise conception cependant, ce n'est pas pour un usage mais pour comprendre.

Donc en résumer comment appeler un fonction/variable d'un .c spécifique en dehors de celui-ci ?

[Sve@r]

Bonjour

comment accéder à la valeur FileNumber propre à chaque .c ou appeler la fonction FileNumber () de chaque .c ? Si toutefois c'est possible sans espaces de noms.

Compilation sources multiples


Ici typiquement

• gcc -c 1.c
• gcc -c 2.c
• gcc -c 3.c

Ces 3 commandes créent chacune leur ".o" correspondant au ".c" nommé. Ensuite le final gcc 1.o 2.o 3.o -o <nom_de_ton_choix_pour_ton_exécutable>. Et si tu veux y rajouter une bibliothèque "toto.so" alors gcc 1.o 2.o 3.o toto.so -o <nom_de_ton_choix_pour_ton_exécutable>. Et si la bibliothèque fait partie des standards, elle se nommera alors "libtoto.so" ce qui te permet en retour un raccourci via l'option "-l" qui signifie "lib<nom de la lib>.so" => gcc 1.o 2.o 3.o -ltoto -o <nom_de_ton_choix_pour_ton_exécutable>.
Ca peut sembler contraignant mais tu as un outil "make" qui, via un langage spécifiant les dépendances noté dans un fichier "Makefile", te permet de recompiler facilement. Surtout que justement le système de dépendances horodatées fait que make ne recompile que ce qui change.

Accessoirement les espaces de noms n'existent pas en C, cela amène la contrainte que les noms de fonctions doivent être uniques pour tout l'exécutable. Donc tes 3 fonctions ne peuvent pas se nommer toutes trois "FileNumber". Sauf si tu veux restreindre la visibilité d'une fonction à un seul source (possible par exemple quand on veut coder des traitements spécifiques non nécessairement accessible du dehors). Mais dans ce cas ta fonction n'est plus accessible depuis un autre source ce qui ne correspond pas à ton but mentionné ici.
Donc interdit de nommer les trois fonctions du même nom. A partir de là, une fois que les fonctions ont toutes un nom bien précis, tu peux appeler chaque fonction depuis n'importe quel endroit de n'importe quel source. C'est l'édition de lien qui fera le lien entre les appels et les fonctions.

Ca a une odeur de très mauvaise conception

Pas forcément. Tu peux découper les grands domaines de ton projet et attribuer un source par domaine.

[foetus]

Ca a une odeur de très mauvaise conception cependant, ce n'est pas pour un usage mais pour comprendre.

Oui c'est la conception qui est mauvaise

Il y a sûrement plusieurs façons de le faire, mais le + direct/ simple, c'est avec 1 tableau.
Tu crées 1 structure avec 1 nom (disons 1 char[50]) et 1 nombre (ton FileNumber).
Tu fais 1 tableau avec cette structure : ainsi tu associes "en 1 seul endroit du code" ton fichier et ton nombre.

Pour la recherche, le + évident c'est de rechercher le nom (contenu dans la structure). Mais tu peux aussi utiliser l'index du tableau pour faire 1 identifiant unique et 1 accès direct.

[Sve@r]

Oui c'est la conception qui est mauvaise
Il y a sûrement plusieurs façons de le faire, mais le + direct/ simple, c'est avec 1 tableau.

J'ai eu l'impression que c'était une question d'ordre général. Comment "en général" appeler une fonctionX se trouvant dans un sourceX depuis une ligne de code se trouvant dans un sourceY...

[foetus]

Ouais, dans ce cas, il faut mieux faire des bibliothèques dynamiques (.dll/ .so) : ainsi on peut charger et décharger 1 bibliothèque à la volée (voire même plus, ajouter de nouvelles bibliothèques et en modifier après compilation)
Et comme chaque bibliothèque peut avoir les même noms pour les fonctions/ variables/ …, cela correspond à la demande.

[run(F) jkldc]

Tout d'abord merci pour la diligence et la précision de votre réponse.
2 points nécessite un éclaircissement:

qu'en est-il des macros et des variables ?

une variable se voit redéfinie à chaque fois qu'une "étiquette" identique est rencontrée, la portée de chaque est donnée façon poupée gigogne.
Pour qu'une variable soit accessible par un autre .c il faut qu'elle soit déclarer extern dans le .c appelant et qu'elle soit global dans le .c la définissant.

par ailleurs il est conseiller de mettre la définition d'une variable extern dans un .h pour que: "surtout le compilateur ne réserver pas un emplacement mémoire maintenant et résout cet emplacement mémoire plus tard : durant de la phase d'édition des liens." car "un fichier de déclaration (un fichier d'extension .h) ne doit en aucun cas réserver d'espace mémoire, sans quoi, si ce fichier est inclut dans plusieurs fichiers .c, la donnée sera instanciée plusieurs fois et une erreur sera produire à la phase d'édition des liens." (source)

pourtant le mécanisme suivant:

Code :

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

1
2
3
4
5
 
#ifndef _MON_H
#define _MON_H   
...
#endif

à ce rôle non ?

Enfin une macro est un remplacement d'une étiquette par du code, du plus simple comme un valeur numérique ou une string, à du code exécutable tel une fonction.
(petite aparté, à la différence d'une fonction il n'y à pas de paramètres, ni de retour ? Corrigez moi si je me trompe.)
On peut la voir comme du sucre syntaxique non ?


Enfin

si tu veux restreindre la visibilité d'une fonction à un seul source (possible par exemple quand on veut coder des traitements spécifiques non nécessairement accessible du dehors).

Comment est-ce possible ? (Ma première idée était de la nichée mais je ne trouve pas ça très élégant. Quant à la réutilisabilité même dans le .c ou elle est définit, elle est nulle.)
Si elle n'est pas déclaré dans le .h elle n'est pas accessible. Mais c'est un traitement global. Tous les .c y accède ou seul le .c ou elle est définit.

J'ai eu l'impression que c'était une question d'ordre général. Comment "en général" appeler une fonctionX se trouvant dans un sourceX depuis une ligne de code se trouvant dans un sourceY...

Oui, oui c'est exactement ça.

Ouais, dans ce cas, il vaut mieux faire des bibliothèques dynamiques (.dll/ .so) : ainsi on peut charger et décharger 1 bibliothèque à la volée (voire même plus, ajouter de nouvelles bibliothèques et en modifier après compilation).

Merci du conseil, cependant je n'en suis pas encore à optimiser mon code.
Néanmoins,

... chaque bibliothèque peut avoir les même noms pour les fonctions/ variables/ …, cela correspond à la demande.

rend caduc

la contrainte que les noms de fonctions doivent être uniques pour tout l'exécutable.

et donc que

tes 3 fonctions ne peuvent pas se nommer toutes trois "FileNumber".

PS:

Il y a sûrement plusieurs façons de le faire, mais le + direct/ simple, c'est avec 1 tableau.
Tu crées 1 structure avec 1 nom (disons 1 char[50]) et 1 nombre (ton FileNumber).
Tu fais 1 tableau avec cette structure : ainsi tu associes "en 1 seul endroit du code" ton fichier et ton nombre.

Pour la recherche, le + évident c'est de rechercher le nom (contenu dans la structure). Mais tu peux aussi utiliser l'index du tableau pour faire 1 identifiant unique et 1 accès direct.

j'ai pas tout compris.

[foetus]

Pour le mécanisme, cela s'appelle des "include guards" (<- lien wikipedia en français)

Pour le caduc, non : puisqu'avec 1 bibliothèque dynamique c'est 1 fichier (.dll/ .so) indépendant de l'exécutable.
Lorsque tu compiles 1 unité de compilation, cela crée 1 fichier .o/ .obj, qui est + ou - de l'assembleur, et sera injecté dans l'exécutable à l'édition des liens.
C'est l'édition qui régle les conflits et les "trucs" manquants et qui crée l'exécutable.

Pour mon idée, c'est 1 table d'association. En gros (mais en C++)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    list_numbers[0].name = "sourceX"; list_numbers[0].number = 3;
    list_numbers[1].name = "sourceY"; list_numbers[1].number = 5;
    list_numbers[2].name = "sourceZ"; list_numbers[2].number = 7;
 
//  ...
 
int FileNumberSum(char* F1, char* F2) {
    int number_F1 = search_number(list_numbers, F1),
        number_F2 = search_number(list_numbers, F2),
 
    return (number_F1  + number_F2);
}

Tu n'as pas remarqué qu'il y a plusieurs directives préprocesseur/ précompilation : #define, #ifdef, #ifndef, #endif, #pragma, ...
Tu peux faire des fonctions avec #define, mais comme c'est 1 "copier-coller" il faut parenthéser ta macro pour ne pas avoir de surprises (@Sve@r dans son message en dessous, donne des exemples)

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#include <stdio.h>
#include <stdlib.h>
 
#define MIN(A, B, RES) \
    if (A < B) { \
        RES = A; \
    } else { \
        RES = B; \
    }
 
 
int main()
{
    int a=2, b=5, c=7, d=-2, res;
 
    MIN(a, b, res)
    printf("Min(%d, %d) : %d\n", a, b, res);
 
    MIN(c, b, res)
    printf("Min(%d, %d) : %d\n", c, b, res);
 
    MIN(d, a, res)
    printf("Min(%d, %d) : %d\n", d, a, res);
 
    MIN(a, c, res)
    printf("Min(%d, %d) : %d\n", a, c, res);
 
    MIN(b, d, res)
    printf("Min(%d, %d) : %d\n", b, d, res);
 
 
    return EXIT_SUCCESS;
}

[Sve@r]

qu'en est-il des macros et des variables ?

Une macro ce n'est pas une variable. C'est une substitution. Dans mon premier schéma c'est traité entre le ".c" et le ".i".
Donc une macro reste limitée au ".c" dans lequel elle se trouve.

Pour qu'une variable soit accessible par un autre .c il faut qu'elle soit déclarer extern dans le .c appelant et qu'elle soit global dans le .c la définissant.

Exact. C'est là la différence entre "déclaration" (on indique qu'elle existe pour que le compilateur ne sois pas gêné lors de l'analyse du source et de la transformation en ".o") et "définition" (on lui donne un espace mémoire).
Donc autant de déclarations que l'on veut mais une seule définition. Et pour simplifier la gestion, on va la définir dans le ".c" contenant le main
Exemple
main.c

Code c :

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

1
2
3
4
5
6
7
void toto();
 
int xxx=123;
 
int main() {
	toto();
}

toto.c

Code c :

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

1
2
3
4
5
#include <stdio.h>
extern int xxx;
void toto() {
	printf("xxx=%d\n", xxx);
}

Compilation (sous Linux en ligne de commande bash): gcc -c main.c toto.c && gcc main.o toto.o -o main puis appel du programme via ./main.

Attention toutefois, ceci nous fait entrer dans le monde des variables globales qui ne sont pas très aimées des programmeurs (enfin des programmeurs qui aiment leur métier). Mais parfois elles sont inévitables (exemple dans les fonctions de communication via kill() et signal()).

De plus, "extern" n'est pas dévolu à l'espace global. Il peut parfaitement être notifié dans la seule fonction qui utilise la variable.
toto.c

Code c :

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

1
2
3
4
5
6
#include <stdio.h>
 
void toto() {
	extern int xxx;
	printf("xxx=%d\n", xxx);
}

Cela permet de mieux suivre les globales et les fonctions qui les utilisent

par ailleurs il est conseiller de mettre la définition d'une variable extern dans un .h pour que: "surtout le compilateur ne réserver pas un emplacement mémoire maintenant et résout cet emplacement mémoire plus tard : durant de la phase d'édition des liens." car "un fichier de déclaration (un fichier d'extension .h) ne doit en aucun cas réserver d'espace mémoire, sans quoi, si ce fichier est inclut dans plusieurs fichiers .c, la donnée sera instanciée plusieurs fois et une erreur sera produire à la phase d'édition des liens." (source)

Ouaip.

pourtant le mécanisme suivant:

Code :

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

1
2
3
4
5
 
#ifndef _MON_H
#define _MON_H   
...
#endif

à ce rôle non ?

Non. Il a juste un rôle "protecteur" l'empêchant d'être inclu plusieurs fois.
Admettons que tu appelles deux fonctions, la première nécessitant "mon.h" et la seconde nécessitant "xxxyyy.h", tu écriras naturellement...

Code c :

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

1
2
#include <xxxyyy.h>
#include <mon.h>

... ce qui est tout à fait normal. Mais si "xxxyyy.h" inclut de son côté "mon.h" sans que tu le saches (tu n'es pas obligé de tout connaitre les ".h" par coeur) ce système évite la redondance (à la première inclusion "_MON_H" n'est pas défini donc il est défini et tout le ".h" est inclut, mais à la seconde comme il l'est déjà il n'est pas ré-inclut une seconde fois).

Enfin une macro est un remplacement d'une étiquette par du code, du plus simple comme un valeur numérique ou une string, à du code exécutable tel une fonction.

C'est un remplacement littéral. Et c'est tellement littéral qu'il faut faire gaffe aux priorités.
Exemple #define CARRE(x) x*x cela amènera un effet de bord si tu écris CARRE(2+3) qui sera traduit par 2+3*2+3 et donnera 11 au lieu de 25.
Ainsi on mettra des parenthèses aux pseudo-paramètres #define CARRE(x) (x)*(x).
Là ça va. Mais ce n'est pas fini car si on écrit #define SOMME(x, y) (x)+(y) on aura un souci analogue avec 2*SOMME(3, 4) qui sera traduit par 2*(3)+(4) et donnera 10 au lieu de 14.
Ainsi on va rajouter aussi des parenthèses à l'expression entière #define SOMME(x,y) ((x)+(y)) et on se croit tranquille. Sauf qu'il existe des opérations implicites (++ et --) qui foutront une zone indémélable si on écrit CARRE(i++). C'est pour cette raison que

• on écrit les macros en majuscules (pour les reconnaitre)
• on recommande de ne pas mettre d'opération implicite dans les paramètres de fonctions (car on n'est jamais sûr que ce soit vraiment une fonction qu'on appelle, exemple les fonctions islower() et autres qui, tout en étant en minuscules, peuvent être des macros).

Et (apparté) c'est ce souci qui a amené la création de fonctions "inline" en C++ qui sont comme des macros sans ces inconvénients. Et aujourd'hui le "inline" est arrivé jusqu'au C.

On peut la voir comme du sucre syntaxique non ?

Oui, mais en se souvenant qu'il y a des précautions.

Comment est-ce possible ? (Ma première idée était de la nichée mais je ne trouve pas ça très élégant. Quant à la réutilisabilité même dans le .c ou elle est définit, elle est nulle.)
Si elle n'est pas déclaré dans le .h elle n'est pas accessible. Mais c'est un traitement global. Tous les .c y accède ou seul le .c ou elle est définit.

Tu définis la fonction en "static" et elle est alors limitée au ".c" dans lequel elle est écrite qui, lui seul, peut l'appeler
Exemple

Code c :

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

1
2
3
4
5
6
7
static int carre(int n) {
	return n*n;
}
 
void toto() {
	int n=carre(123);
}

Tu ne pourras pas appeler "carre" depuis un autre source. Mais en contrepartie tu auras le droit d'écrire, dans un autre source, une autre fonction de même nom "carre()" qui fera un autre travail.

Néanmoins rend caduc rend caduc la contrainte que les noms de fonctions doivent être uniques pour tout l'exécutable.

Exact. Mais tu devras indiquer, à la compilation, quelle librairie tu veux utiliser et tu n'auras accès qu'à la fonction FileNumber de cette librairie là, pas aux autres. Et si tu veux accéder à une autre il faudra recompiler en indiquant l'autre lbrairie et en perdant alors l'accès à la première.
Mais ça peut être utile si par exemple tu veux créer un programme un peu modulable. Dans tel environnement il utilisera telle lib, dans tel autre il utilisera telle autre lib. Les lib ont les mêmes noms de fonctions donc ton main() ne change pas. C'est à la compilation que tu définis la lib à utiliser.

[foetus]

C'est à la compilation que tu définis la lib à utiliser.

tu peux faire la recherche des bibliothèques dans 1 dossier spécifique … à l'instar des plug-ins

[kaitlyn]

Salut,

comment accéder à la valeur FileNumber propre à chaque .c ou appeler la fonction FileNumber () de chaque .c ? Si toutefois c'est possible sans espaces de noms.

On pourrait faire en sorte que ça soit transparent grâce entre autres à une forme de métaprogrammation à base de macro avec l’opérateur de concaténation ##, et permettre l'usage d'un même nom de fonction f() dans chaque source. À la compilation il sera étendu en quelque chose d'unique sur la base du nom de chacun des fichiers sources c1, c2, .... --> f_c1(), f_c2() ...