Année universitaire 2002-2003

Licence d'informatique Module 4 - partie "C / shell" Travaux dirigés 9 : 1. Compilation séparée. 2. Utilisation de l'utilitaire make. 3. Les pointeurs génériques. 4. Concept de pile. 5. Exercice 1 : module de gestion d'une pile. 6. Exercice 2 : fichier makefile.

1. Compilation séparée.

Lors de l'élaboration d'un gros projet, il est nécessaire de découper le programme en plusieurs "modules". Il est alors intéressant de pouvoir compiler ces différents modules séparément. Chacun des "fichiers sources" constituant un projet sera compilé séparément, ce qui aura pour résultat de produire un "fichier objet". Par la suite, les différents fichiers objets, ainsi que le code compilé des fonctions standard du C utilisées, seront "liés" grâce à "l'éditeur de liens", afin de produire le "fichier exécutable". Parmi les avantages de la compilation séparée, on peut citer :

• Clarté et lisibilité : la programmation dite "modulaire" permet de refléter l'organisation générale d'un gros projet et facilite sa mise au point.

• Réutilisabilité : un module réalisé pour une application donnée pourra être facilement réutilisé dans le cadre d'autres projets. En outre, la réalisation des modules pourra être distribuée au sein d'une équipe de programmeurs qui les mettront au point indépendamment les uns des autres (cf. le programme qui sera réalisé, d'une part, lors de la présente séance de travaux dirigés et, d'autre part, lors de la séance 7 de travaux pratiques).

• Confidentialité : dans certaines situations, on pourra être amené à ne pas fournir le fichier source d'un module, mais seulement le fichier objet correspondant. L'inconvénient est qu'on perd la "portabilité" du module, puisque le fichier objet qui lui est associé dépend de l'ordinateur et du compilateur utilisés.

Généralement, en langage C, un module est constitué :

• D'une part, d'un fichier dont le nom possède l'extension .c, qui contient la définition d'un certain nombre de fonctions.

• D'autre part, d'un fichier associé au précédent, dont le nom possède l'extension.h, souvent appelé "fichier d'en-tête" ("header file" en anglais, d'où l'extension.h), qui contient les "éléments" que devra connaître un utilisateur du module. Ces éléments peuvent être des définitions de constantes, de macro-instructions ou de types, des déclarations de variables globales (définitions ou références) ou des références à des fonctions définies par ailleurs dans le fichier d'extension.c associé.

Le fichier d'en-tête d'un module constitue en fait "l'interface" de ce module. Un utilisateur pourra être amené à faire appel aux éléments contenus dans un fichier d'en-tête, et devra pour cela inclure ce fichier dans son fichier source, grâce à une directive d'inclusion de fichier (mot-clé #include).

Exemple :

Supposons qu'un module soit composé des deux fichiers suivants :

module.c

#include "module.h" static int f1(int x) { ... } int f2(int x) { ... } int f3(mon_type a) { ... }

module.h

#include <stdio.h> #define VRAI 1 #define FAUX 0 typedef struct { size_t x; int y; } mon_type; float var_globale; extern int f2(int x); extern int f3(mon_type a);

Si un programmeur veut utiliser ce module, il lui suffit de placer la directive d'inclusion de fichier #include "module.h" dans son fichier source. Seront alors connues les constantes VRAI et FAUX, le type mon_type, la variable globale var_globale (on conseille d'éviter l'utilisation de telles variables), ainsi que les fonctions f2 et f3. En revanche, la fonction f1 ne sera pas visible car elle est confidentielle au fichier module.c (mot-clé static).

La compilation de ce module se fera par la commande :

    gcc -ansi -pedantic -Wall -Werror -c module.c

qui produira le fichier objet module.o

Si le fichier principal du projet (contenant le programme principal main) s'appelle principal.c, alors la commande :

gcc -ansi -pedantic -Wall -Werror -c principal.c

produira le fichier objet correspondant principal.o

Enfin, l'édition de liens :

gcc -ansi -pedantic -Wall -Werror -o principal module.o principal.o

produira le fichier exécutable principal

Remarques :

• Il faut prendre garde à bien écrire la directive d'inclusion de fichier sous la forme :

#include "module.h"

et non pas sous la forme :

#include <module.h>

car le fichier module.h ne se trouve pas dans le répertoire /usr/include !

• Le mot-clé extern devant la référence à une fonction (cf. les références aux fonctions f2 et f3, dans le fichier module.h) est facultatif, mais il est d'usage de l'y faire apparaître, afin de souligner l'analogie entre fonctions et variables globales : une référence est précédée du mot-clé extern, contrairement à une définition.

2. Utilisation de l'utilitaire make.

L'utilitaire make permet de gérer la compilation séparée d'un projet, de telle sorte que seules les commandes de compilation ou d'édition de liens nécessaires soient exécutées, lors de la mise à jour d'un fichier exécutable. L'utilisation de make nécessite l'écriture d'un "fichier de description des dépendances" entres les différents fichiers constituant un projet.

2.1. Syntaxe du fichier de description des dépendances.

Chaque dépendance est décrite selon la syntaxe suivante :

    fichier_cible:liste_fichiers_requis
    <tabulation>commande_associée

Le nom du fichier qui doit être mis à jour est fichier_cible, et liste_fichiers_requis est la liste des noms de fichiers (séparés par des espaces) dont dépend fichier_cible et qui sont susceptibles d'être modifiés par l'utilisateur. En d'autres termes, ces fichiers sont nécessaires à la création de fichier_cible et, s'ils sont modifiés, alors fichier_cible doit être mis à jour. Une mise à jour sera donc effectuée si la date de dernière modification d'au moins un des fichiers requis est postérieure à la date de dernière mise à jour de fichier_cible. Quant à commande_associée, il s'agit de la commande qui va permettre la mise à jour de fichier_cible.Le symbole <tabulation> représente un caractère de tabulation. La présence de ce caractère est indispensable. Enfin, les lignes commençant par un caractère #, dans un fichier de description des dépendances, sont des lignes de commentaires.

2.2. Lancement de l'utilitaire  make.

Si le fichier de description des dépendances s'appelle makefile ou Makefile, il suffit de taper :

make

et seules les tâches nécessaires seront exécutées. Si ce fichier porte un autre nom, par exemple fichier_dépendances.mk (on utilise conventionnellement l'extension .mk dans ce cas), il faut taper :

make -f fichier_dépendances.mk

L'utilitaire make va tout d'abord vérifier la nécessité de mettre à jour le premier fichier cible apparaissant dans le fichier de description des dépendances. Si ce fichier est à jour, aucune autre vérification ne sera réalisée. C'est pourquoi il est nécessaire de placer le fichier qui constitue l'objectif final en tête du fichier de description des dépendances (en général, il s'agit du fichier contenant le programme exécutable).

Exemple :

Pour l'exemple précédent, on peut écrire le fichier de description des dépendances suivant :

makefile

# Création de l'exécutable par édition de liens. principal:principal.o module.o gcc -ansi -pedantic -Wall -Werror -o principal principal.o module.o # Création de principal.o par compilation, sans édition de liens. principal.o:principal.c module.h gcc -ansi -pedantic -Wall -Werror -c principal.c # Création de module.o par compilation, sans édition de liens. module.o:module.c module.h gcc -ansi -pedantic -Wall -Werror -c module.c

Remarque :

Il peut paraître surprenant qu'au moment de l'édition de liens, on ne doive pas écrire le nom d'un fichier objet issu de la compilation du fichier source correspondant au fichier d'en-tête stdio.h, et contenant, par exemple, le code binaire des fonctions printf et scanf, alors que la directive d'inclusion du fichier stdio.h apparaît dans le fichier module.h. En fait, cette exception est valable pour les "bibliothèques standard", et en particulier pour les trois bibliothèques suivantes :

• La bibliothèque des "entrées/sorties standard", de fichier d'en-tête stdio.h, dont l'inclusion assure, entre autres : la définition des types size_t et FILE ; la définition des constantes symboliques NULL, EOF, stdin, stdout, stderr, SEEK_SET, SEEK_CUR et SEEK_END ; la définition de la macro-instruction getchar ; les déclarations des fonctions fclose, fflush, fopen, fprintf, fscanf, printf, scanf, fread, fwrite, fseek et feof.

• La "bibliothèque standard", de fichier d'en-tête stlib.h, dont l'inclusion assure, entre autres : la définition du type size_t ; la définition de la constante symbolique NULL ; les déclarations des fonctions free, malloc, exit, system, qsort.

• La bibliothèque de "gestion des chaînes de caractères", de fichier d'en-tête string.h, dont l'inclusion assure, entre autres : la définition du type size_t ; la définition de la constante symbolique NULL ; les déclarations des fonctions strcpy, strncpy, strcat, strncat, strcmp, strncmp, strlen.

En revanche, si on utilise les fonctions mathématiques dont les déclarations sont assurées par l'inclusion du fichier math.h (par exemple : les fonctions trigonométriques cos, sin, tan, la puissance pow, la racine carrée sqrt, la valeur absolue fabs, la "partie entière" floor, etc...), on doit rajouter, à la fin de la commande d'édition de liens, le paramètre -lm (abréviation de librairie mathématique). Dans ce cas, la commande d'édition de liens s'écrira, par exemple :

gcc -ansi -pedantic -Wall -Werror -o principal principal.o module.o -lm

3. Les pointeurs génériques.

Le type "pointeur générique", ou "pointeur universel", est défini par :

void *

L'intérêt de ce type est de pouvoir écrire des fonctions "génériques", c'est-à-dire par exemple des fonctions qui peuvent être appelées avec des paramètres effectifs de types inconnus a priori, car un paramètre formel de type void *, comme une variable de type void *, peut recevoir comme valeur n'importe quelle adresse. Nous avons déjà rencontré au moins deux cas de "généricité" :

• La fonction malloc (cf. la séance 5 de travaux dirigés), déclarée dans le fichier stdlib.h, permet la réservation d'un espace mémoire quelconque, sans référence à un type particulier. Or, cette fonction possède l'en-tête suivant :

void *malloc(size_t taille)

qui fait bien intervenir le type void *

• La macro-instruction ABS (cf. la séance 7 de travaux dirigés) permet le calcul de la valeur absolue d'une valeur numérique de type quelconque (char, short, int, long, float, double, etc...).

On peut mesurer, sur ces deux exemples, tout l'intérêt que représente la généricité. On ne s'intéresse ici qu'aux fonctions génériques, et pas aux macro-instructions.

Le type void * est indispensable à l'écriture de fonctions génériques. Il existe deux manières de rendre une fonction générique : soit elle retourne une valeur de type void *, soit un de ses paramètres formels au moins est de type void *

3.1. Fonctions retournant une valeur de type void *

Pour illustrer ce cas, nous allons prendre l'exemple de la fonction malloc. La valeur qu'elle retourne, de type void *, peut être affectée à un un pointeur de n'importe quel type, comme le montre l'exemple suivant :

char *p_car; /* La variable p_car est un pointeur de caractère. */
p_car=malloc(3);
*p_car='O';
*(p_car+1)='K';
*(p_car+2)='\0';
printf("%s\n",p_car);

Cette séquence est compilable, et produit l'affichage de : OK

La valeur retournée par la fonction malloc peut également être affectée à une variable de type "pointeur générique", comme le montre la séquence suivante :

void *p; /* La variable p est un pointeur générique. */
p=malloc(3);
strcpy(p,"OK");
printf("%s\n",(char *)p);

Cette séquence est compilable. Elle affiche : OK

Cependant, cette dernière possibilité est fortement déconseillée, car elle est sujette à de nombreuses restrictions, comme le montre la séquence suivante :

void *p; /* La variable p est un pointeur générique. */
p=malloc(3);
*p='O';
*(p+1)='K';
*(p+2)='\0';
printf("%s\n",(char *)p);

Cette séquence n'est pas compilable, car les "objets pointés" *p, *(p+1) et *(p+2), qui ne sont pas typés, ne peuvent pas recevoir de valeurs typées (alors qu'une variable de type void * peut recevoir comme valeur n'importe quelle adresse), ce qui provoque l'affichage de trois messages d'erreur et de trois messages d'avertissement. En outre, il y a une ambiguïté sur la valeur des adresses (p+1) et (p+2), puisque le compilateur ne connaît pas le type pointé par p, et ceci provoque l'affichage de deux autres messages d'avertissement.

Une possibilité pour rendre cette dernière séquence compilable est de convertir les expressions p, (p+1) et (p+2) en pointeurs de caractères, c'est-à-dire :

void *p; /* La variable p est un pointeur générique. */
p=malloc(3);
*((char *)p)='O';
*(((char *)p)+1)='K';
*(((char *)p)+2)='\0';
printf("%s\n",(char *)p);

Cette séquence est compilable et produit l'affichage de : OK

3.2. Fonctions dont un paramètre formel au moins est de type void *

Pour illustrer ce cas, nous allons donner l'exemple d'une fonction permettant d'échanger les valeurs pointées par deux pointeurs de même type, et ce quel que soit le type commun de ces deux pointeurs. Une telle fonction peut être écrite de la façon suivante :

void echange(void *p1,void *p2,size_t taille) { char aux; size_t i; for (i=0;i<taille;i++) { aux=((char *)p2)[i]; ((char *)p2)[i]=((char *)p1)[i]; ((char *)p1)[i]=aux; } }

où taille représente le nombre d'octets occupés par les deux valeurs pointées.

Les programmes programme1.c et programme2.c donnent deux exemples d'appels de la fonction générique echange :

programme1.c

#include <stdio.h> #include <stdlib.h> void echange(void *p1,void *p2,size_t taille) { char aux; size_t i; for (i=0;i<taille;i++) { aux=((char *)p2)[i]; ((char *)p2)[i]=((char *)p1)[i]; ((char *)p1)[i]=aux; } } int main(void) { int i1=7,i2=5; printf("Avant échange : %d %d\n",i1,i2); echange(&i1,&i2,sizeof(int)); printf("Après échange : %d %d\n",i1,i2); exit(0); }

programme2.c

#include <stdio.h> #include <stdlib.h> #define T 8 void echange(void *p1,void *p2,size_t taille) { char aux; size_t i; for (i=0;i<taille;i++) { aux=((char *)p2)[i]; ((char *)p2)[i]=((char *)p1)[i]; ((char *)p1)[i]=aux; } } int main(void) { char ch1[T]="OK",ch2[T]="Va bene"; printf("Avant échange : %s %s\n",ch1,ch2); echange(ch1,ch2,T); printf("Après échange : %s %s\n",ch1,ch2); exit(0); }

Dans programme1.c, p1 et p2 reçoivent des adresses d'entiers, alors que dans programme2.c, p1 et p2 reçoivent des adresses de caractères.

Attention :

Une variable ou un paramètre formel de type void * peuvent recevoir la valeur d'un pointeur de type quelconque. Réciproquement, un pointeur non générique peut recevoir une valeur de type void *, mais cette opération comporte des risques dus à des contraintes d'alignement en mémoire (car tout pointeur ne peut pas avoir comme valeur n'importe quelle adresse), risques qui peuvent se traduire par une erreur à l'exécution du type Bus error. Il est cependant à noter que l'instruction p=malloc(3); est toujours valide, quel que soit le type du pointeur p, car l'adresse retournée par la fonction malloc présente les meilleures garanties possibles d'alignement en mémoire.

4. Concept de pile.

Le concept de pile associe une façon de stocker les données en mémoire et une façon de gérer leur accès. Généralement, on utilise une liste chaînée pour gérer une pile. Lorsqu'une nouvelle donnée doit être enregistrée, elle est placée au sommet de la pile (fonction empiler), et lorsqu'une donnée doit être retirée, on extrait celle qui est située au sommet de la pile (fonction depiler), comme l'indiquent les schémas suivants :

5. Exercice 1.

Le but de cet exercice est d'écrire un module permettant la manipulation d'une pile. On souhaite que ce module soit "générique", c'est-à-dire qu'il permette de manipuler n'importe quel type de pile. Ce module se composera de deux fichiers, comme cela a été expliqué dans le paragraphe 1 :

• Un fichier pile.c, contenant la définition d'un certain nombre de fonctions génériques permettant la manipulation d'une pile.

• Un fichier d'en-tête pile.h, contenant la déclaration des fonctions de pile.c, ainsi que la définition du type de structure utilisée pour la réalisation de la pile.

5.1. Écriture du fichier pile.h

1) Dans le fichier pile.h, on doit définir le "type générique" cellule :

typedef struct cell
{
void *p_info;
struct cell *p_suivant;
} cellule;

Le premier champ de cette structure est un pointeur générique (cf. paragraphe 3) de nom p_info, qui pointera sur un "élément", alors que son deuxième champ est un pointeur sur un élément de type cellule. Voici la représentation graphique d'une pile constituée selon ce principe et contenant deux éléments :

La seule contrainte, pour un utilisateur de ce module, sera d'effectuer, juste avant l'empilage d'un nouvel élément, l'allocation dynamique (grâce à la fonction malloc) d'un espace mémoire qui permettra de stocker cet élément.

2) Par ailleurs, on doit faire référence, dans le fichier d'en-tête pile.h (à l'aide du mot-clé extern, et en faisant suivre chaque en-tête de fonction d'un point-virgule), aux fonctions qui seront définies dans pile.c, à l'exception de la fonction pile_vide, qui sera définie de manière confidentielle dans le fichier pile.c, à savoir :

• creer_pile, d'en-tête :

cellule *creer_pile(void)

Cette fonction retourne l'adresse NULL.

• empiler, d'en-tête :

int empiler(void *p_element,cellule **pp_pile)

Cette fonction :

• Empile, au sommet de la pile pointée par *pp_pile, une nouvelle structure de type cellule, dont le champ p_info, de type void *, devra pointer sur l'élément pointé par p_element.
  
  
• Retourne 0 en cas de problème d'allocation de mémoire, et 1 sinon.

• depiler, d'en-tête :

void *depiler(cellule **pp_pile)

Cette fonction doit réaliser les tâches suivantes :

• Si la pile n'est pas vide :

• Suppression de la structure se trouvant au sommet de la pile pointée par *pp_pile.

• Renvoi de la valeur du champ p_info de cette structure.

• Si la pile est vide : renvoi de l'adresse NULL.

• sommet_pile, d'en-tête :

void *sommet_pile(cellule *p_pile)

Cette fonction renvoie la valeur du champ p_info de la cellule se trouvant au sommet de la pile, et NULL si la pile est vide.

• hauteur_pile, d'en-tête :

int hauteur_pile(cellule *p_pile)

Cette fonction renvoie la hauteur de la pile pointée par p_pile.

• liberer_pile, d'en-tête :

void liberer_pile(cellule **pp_pile)

Cette fonction libère tout l'espace mémoire occupé par la pile pointée par *pp_pile. On aura intérêt, pour la réaliser, à utiliser les fonctions pile_vide et depiler.

5.2. Écriture du fichier pile.c

1) Comme la plupart des fonctions définies dans pile.c utilisent le type cellule défini dans pile.h, il faut faire apparaître dans pile.c la directive d'inclusion de fichier suivante :

#include "pile.h"

2) Comme on utilise la constante NULL et les fonctions malloc et free, on doit inclure le fichier stdlib.h

3) Par ailleurs, comme certaines fonctions définies dans pile.c utilisent la fonction pile_vide, il faut faire apparaître dans pile.c la définition confidentielle de cette fonction, d'en-tête :

static int pile_vide(cellule *p_pile)

Cette fonction retourne 1 si la pile pointée par p_pile est vide, et 0 sinon.

4) Enfin, il faut écrire dans pile.c la définition des fonctions énumérées précédemment (l'ordre d'apparition de ces fonctions est indifférent).

Lors de la séance 7 de travaux pratiques, il sera demandé d'écrire un fichier, de nom gestion.c, contenant un programme qui fera appel aux différents éléments déclarés dans le fichier pile.h.

6. Exercice 2.

Écrire un fichier de description des dépendances, de nom makefile, permettant la compilation du fichier gestion.c et la production d'un fichier exécutable, de nom gestion. Pour lancer la compilation optimisée de gestion.c, il suffira de taper dans la fenêtre système :

make