Discussion :

[Pif_Paf_Pouf]

Bonjour,

Voila je ne sais si l'endroit est bien choisi pour poster ma question mais la voila:

En C:Quelle différence y a t il entre l'éditeur de lien et le préprocesseur?

En effet si j'ai bien pigé:
*)l'éditeur de lien: "permet d'intégrer dans le fichier final tous les éléments annexes (fonctions ou librairies) "
Et le
*)préprocesseur:qui permet d'inclure dans le fichier source les éléments référencés par les instructions situées au début du fichier source (instructions précédées du caractère #).

---->Quelle différence et qu'elle est l'utilité du préprocesseur?

Merci beaucoup.

[Médinoc]

Le préprocesseur est généralement utilisé pour inclure au fichier source des parties répétitives qu'il faudrait inclure dans chaque fichier source pour que ça marche (notamment, les déclarations de fonction). Il permet également des remplacements (via les macros) et d'une manière générale, agit "avant" la compilation.

L'éditeur de liens regroupe ensemble le produit de la compilation des différents fichiers source (ce qu'on appelle le code objet), ainsi que le code objet importé des différentes bibliothèques statiques.

[Obsidian]

Bonjour,

On peut aussi présenter les choses en disant que le préprocesseur intervient avant la compilation proprement dite et l'éditeur de liens après. Mais ce n'est qu'une particularité, pas une définition.

Le préprocesseur va intervenir sur la forme uniquement, pour préparer ton programme à être compilé. Concrètement, c'est lui qui va s'occuper de résoudre toutes les macros auxquelles tu fais référence dans ton code. Ce qui est important de retenir, c'est qu'elles vont réellement être substituées de façon littérale par ce qu'elles représentent, et que le compilateur ne saura jamais si ce qu'il lit était initialement la valeur d'une de ces macros ou si c'est le programmeur qui l'a directement écrit comme ça. D'où cet exemple célèbre :

Code C :

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

1
2
3
4
5
6
7
8
#define SIX 1 + 5
#define NEUF 8 + 1
 
int main(void)
{
    printf ("%d\n", SIX * NEUF);
    return 0;
}

Code Shell :

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

1
2
$ ./programme
42

… au lieu de 54. « SIX » va être substitué par « 1 + 5 » et « NEUF » par « 8 + 1 », ce qui donnera littéralement « 1 + 5 * 8 + 1 » dans le corps de printf, et la priorité des opérateurs fera que le résultat de l'expression sera en fait celui de « 5 * 8 + 1 + 1 », donc 42.

C'est également lui qui va s'occuper de gérer les « #include » et surtout les blocs conditionnels « #if ». Par exemple, quand tu écris :

Code C :

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

1
2
3
#ifdef GL_VERSION_1_1
    glLoadIdentity();
#endif

… le code à l'intérieur du bloc ne sera transmis au compilateur que si la GL_VERSION_1_1 est vrai. Sinon, il n'en verra jamais la couleur. C'est pratique pour éviter d'insérer du code inutile dans un exécutable final, et c'est même nécessaire dans ce genre de cas car autrement, même si OpenGL n'était pas disponible, ton compilateur serait quand même obligé de faire référence à la fonction (même à l'intérieur d'un « if() » ordinaire évalué à l'exécution). Tu ne pourrais alors jamais finaliser l'édition des liens et tu serais dans l'incapacité de produire ton exécutable.

[Pif_Paf_Pouf]

Bonjour,

Si j'ai bien compris le préprocesseur n'est la que pour des problèmes de lisibilités du code,car c'est lui qui ,par la suite,"intègre"les "macros".Ce qui ns permet dons d'utiliser "les macros" .
L’éditeur de lien quand à lui fait vraiment "le job" de convertir le langage C en langage compréhensible par la machine.

@Obsidian//
Je ne connais pas le langage Shell.

[Médinoc]

L’éditeur de lien qd à lui fait vraimt "le job" de convertir le langage C en langage compréhensible par la machine.

Non, ça c'est le travail du compilateur. L'éditeur de liens sert à assembler les morceaux compilés séparément.

...Et les mettre dans un format accepté par le système d'exploitation (en-tête, etc.)

[Obsidian]

Si j'ai bien compris le préprocesseur n'est la que pour des prbs de lisibilités du code,car c'est lui qui ,par la suite,"intègre"les "macros".Ce qui ns permet dons d'utiliser "les macros" .

« lisibilité » n'est pas le terme exact. Le travail du préprocesseur est d'effectuer justement tous les préparatifs nécessaires préalables à l'interprétation du code source par le compilateur.

« #include » est un très bon exemple mais dans le cas de figure que je t'ai présenté, une compilation conditionnelle permet également de ne présenter à ce compilateur que la partie du code qui, ici, correspond à l'environnement. Si tu avait utilisé un bloc « if » ordinaire, non seulement les conditions auraient été évaluées à l'exécution (et les macros auraient donc dû être des variables) mais les deux fonctions auraient quand même dûes être compilées même si l'une d'entre elles n'aurait jamais été appelée dans les faits. Pire, cela t'aurait obligé à lier ce programme avec les bonnes bibliothèques et, par conséquent, à les installer pour rien.

Pour le reste, la réponse de Médinoc est la meilleure.

Je ne connais pas le langage Shell.

C'est ce qui forme l'invite de commande sur les systèmes UNIX. Ce n'était là que pour montrer que je lançais le programme décrit juste au dessus.

[Pif_Paf_Pouf]

Ok.


Merci de vos réponses je pense avoir pigé.

Je mets donc en résolu Mais surtout n'hésitez a apporté encore plus de de précisions c'est toujours utile.

[o_Nejma]

Bonjour,
Je pense que Médinoc et Obsidian ont bien clarifié "Différence entre l'éditeur de lien et le préprocesseur?". J'aimerais juste ajouter un exemple de sortie du préprocesseur:
exemple.c:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include "exemple.h"
 
int main()
{
 int data;
 
 data = MAX - MIN;
 
 traitement();
 
 return data;
}

exemple.h:

Code :

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

1
2
3
4
5
6
7
#define MAX 20
 
#define MIN 11
 
int traitement();
int traitement()
{return 6;}

Fichier préprocessé: exemple.i

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
# 1 "exemple.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "exemple.c"
# 1 "exemple.h" 1
 
 
 
 
int traitement();
int traitement()
{return 6;}
# 2 "exemple.c" 2
 
int main()
{
 int data;
 
 data = 20 - 11;
 
 traitement();
 
 return data;
}

cordialement,

[Sve@r]

Bonjour

Obsidian a bien montré le problème qu'amène la substitution des macros mal préparées comme celle-ci

Code c :

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

1
2
#define CARRE(x)     x*x
CARRE(2+3)

qui sera traduit en 2+3*2+3 et qui donnera 11 au lieu de 25.

Pour se protéger ce danger, on encadre chaque élément de parenthèses =>#define CARRE(x) (x)*(x).
Ainsi CARRE(2+3) sera traduit en (2+3)*(2+3) et donnera alors correctement 25.

Ensuite il y en a un second lié à la macro elle-même et son intégration avec le reste comme ici

Code c :

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

1
2
#define SOMME(x, y)     (x)+(y)
2 * SOMME(2,3)

qui sera traduit en 2*(2)+(3) et qui donnera 7 au lieu de 10.

Pour se protéger de ce second soucis, on encadre aussi la macro de parenthèses =>#define SOMME(x,y) ((x)+(y)).
Ainsi 2 * SOMME(2,3) sera traduit en 2 * ((2)+(3)) et donnera alors ici correctement 10.

Il y a ensuite un 3° soucis lié à la répétition de certains éléments. Ainsi

Code c :

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

1
2
#define CARRE(x)     ((x)*(x))
CARRE(i++)

sera traduit en ((i++)*(i++)). Là non seulement le résultat ne sera certainement pas celui escompté mais en plus i aura été incrémenté 2 fois. Et il n'y a aucun moyen d'empêcher cela... sauf en évitant les "i++" dans les macros. C'est d'ailleurs à cet effet qu'on écrit généralement les macros en majuscules: afin justement de pouvoir les reconnaitre pour éviter d'y mettre "i++"...