Chapitre 7 La programmation modulaire ~ reading

Dès que l'on écrit un programme de taille importante ou destiné à être utilisé et maintenu par d'autres personnes, il est indispensable de se fixer un certain nombre de règles d'écriture. En particulier, il est nécessaire de fractionner le programme en plusieurs fichiers sources, que l'on compile séparemment.

Ces règles d'écriture ont pour objectifs de rendre un programme lisible, portable, réutilisable, facile à maintenir et à modifier.

7.1 Principes élémentaires

Trois principes essentiels doivent guider l'écriture d'un programme C.

L'abstraction des constantes littérales

L'utilisation explicite de constantes littérales dans le corps d'une fonction rend les modifications et la maintenance difficiles. Des instructions comme :

fopen("mon_fichier", "r");
perimetre = 2 * 3.14 * rayon;

sont à proscrire.

Sauf cas très particuliers, les constantes doivent être définies comme des constantes symboliques au moyen de la directive #define.

La factorisation du code

Son but est d'éviter les duplications de code. La présence d'une même portion de code à plusieurs endroits du programme est un obstacle à d'éventuelles modifications. Les fonctions doivent donc être systématiquement utilisées pour éviter la duplication de code. Il ne faut pas craindre de définir une multitude de fonctions de petite taille.

La fragmentation du code

Pour des raisons de lisibilité, il est nécessaire de découper un programme en plusieurs fichiers. De plus, cette règle permet de réutiliser facilement une partie du code pour d'autres applications. Une possibilité est de placer une partie du code dans un fichier en-tête (ayant l'extension .h) que l'on inclut dans le fichier contenant le programme principal à l'aide de la directive #include. Par exemple, pour écrire un programme qui saisit deux entiers au clavier et affiche leur produit, on peut placer la fonction produit dans un fichier produit.h, et l'inclure dans le fichier main.c au moment du traitement par le préprocesseur.

/**********************************************************************/
/***  fichier: main.c                                               ***/
/***  saisit 2 entiers et affiche leur produit                      ***/
/**********************************************************************/

#include <stdlib.h>
#include <stdio.h>
#include "produit.h"

int main(void)
{
  int a, b, c;
  scanf("%d",&a);
  scanf("%d",&b);
  c = produit(a,b);
  printf("\nle produit vaut %d\n",c);
  return EXIT_SUCCESS;
}

/**********************************************************************/
/***  fichier: produit.h                                            ***/
/***  produit de 2 entiers                                          ***/
/**********************************************************************/

int produit(int, int);

int produit(int a, int b)
{
  return(a * b);
}

Cette technique permet juste de rendre le code plus lisible, puisque le fichier effectivement compilé (celui produit par le préprocesseur) est unique et contient la totalité du code.

Une méthode beaucoup plus pratique consiste à découper le code en plusieurs fichiers sources que l'on compile séparemment. Cette technique, appelée compilation séparée, facilite également le débogage.

7.2 La compilation séparée

Si l'on reprend l'exemple précédent, le programme sera divisé en deux fichiers : main.c et produit.c. Cette fois-ci, le fichier produit.c n'est plus inclus dans le fichier principal. Les deux fichiers seront compilés séparemment ; les deux fichiers objets produits par la compilation seront liés lors l'édition de liens. Le détail de la compilation est donc :

gcc -c produit.c
gcc -c main.c
gcc main.o produit.o

La succession de ces trois commandes peut également s'écrire

gcc produit.c main.c

Toutefois, nous avons vu au chapitre 4 qu'il était risqué d'utiliser une fonction sans l'avoir déclarée. C'est ici le cas, puisque quand il compile le programme main.c, le compilateur ne dispose pas de la déclaration de la fonction produit. L'option -Wall de gcc signale

main.c:15: warning: implicit declaration of function `produit'

Il faut donc rajouter cette déclaration dans le corps du programme main.c.

7.2.1 Fichier en-tête d'un fichier source

Pour que le programme reste modulaire, on place en fait la déclaration de la fonction produit dans un fichier en-tête produit.h que l'on inclut dans main.c à l'aide de #include.

Une règle d'écriture est donc d'associer à chaque fichier source nom.c un fichier en-tête nom.h comportant les déclarations des fonctions non locales au fichier nom.c, (ces fonctions sont appelées fonctions d'interface) ainsi que les définitions des constantes symboliques et des macros qui sont partagées par les deux fichiers. Le fichier en-tête nom.h doit être inclus par la directive #include dans tous les fichiers sources qui utilisent une des fonctions définies dans nom.c, ainsi que dans le fichier nom.c. Cette dernière inclusion permet au compilateur de vérifier que la définition de la fonction donnée dans nom.c est compatible avec sa déclaration placée dans nom.h. C'est exactement la procédure que l'on utilise pour les fonctions de la librairie standard : les fichiers .h de la librairie standard sont constitués de déclarations de fonctions et de définitions de constantes symboliques.

Par ailleurs, il faut faire précéder la déclaration de la fonction du mot-clef extern, qui signifie que cette fonction est définie dans un autre fichier. Le programme effectuant le produit se décompose donc en trois fichiers de la manière suivante.

/**********************************************************************/
/***  fichier: produit.h                                            ***/
/***  en-tete de produit.c                                          ***/
/**********************************************************************/

extern int produit(int, int);

/**********************************************************************/
/***  fichier: produit.c                                            ***/
/***  produit de 2 entiers                                          ***/
/**********************************************************************/
#include "produit.h"

int produit(int a, int b)
{
  return(a * b);
}

/**********************************************************************/
/***  fichier: main.c                                               ***/
/***  saisit 2 entiers et affiche leur produit                      ***/
/**********************************************************************/

#include <stdlib.h>
#include <stdio.h>
#include "produit.h"

int main(void)
{
  int a, b, c;
  scanf("%d",&a);
  scanf("%d",&b);
  c = produit(a,b);
  printf("\nle produit vaut %d\n",c);
  return EXIT_SUCCESS;
}

Une dernière règle consiste à éviter les possibilités de double inclusion de fichiers en-tête. Pour cela, il est recommandé de définir une constante symbolique, habituellement appelée NOM_H, au début du fichier nom.h dont l'existence est précédemment testée. Si cette constante est définie, c'est que le fichier nom.h a déjà été inclus. Dans ce cas, le préprocesseur ne le prend pas en compte. Sinon, on définit la constante et on prend en compte le contenu de nom.h. En appliquant cette règle, le fichier produit.h de l'exemple précédent devient :

/**********************************************************************/
/***  fichier: produit.h                                            ***/
/***  en-tete de produit.c                                          ***/
/**********************************************************************/

#ifndef PRODUIT_H
#define PRODUIT_H

extern int produit(int, int);
#endif /* PRODUIT_H */

En résumé, les règles d'écriture sont les suivantes :

A tout fichier source nom.c d'un programme on associe un fichier en-tête nom.h qui définit son interface.
Le fichier nom.h se compose :
- des déclarations des fonctions d'interface (celles qui sont utilisées dans d'autres fichiers sources) ;
- d'éventuelles définitions de constantes symboliques et de macros ;
- d'éventuelles directives au préprocesseur (inclusion d'autres fichiers, compilation conditionnelle).
Le fichier nom.c se compose :
- de variables permanentes, qui ne sont utilisées que dans le fichier nom.c ;
- des fonctions d'interface dont la déclaration se trouve dans nom.h ;
- d'éventuelles fonctions locales à nom.c.
Le fichier nom.h est inclus dans le fichier nom.c et dans tous les autres fichiers qui font appel à une fonction d'interface définie dans nom.c.

Enfin, pour plus de lisibilité, il est recommandé de choisir pour toutes les fonctions d'interface définies dans nom.c un identificateur préfixé par le nom du fichier source, du type nom_fonction.

7.2.2 Variables partagées

Même si cela doit être évité, il est parfois nécessaire d'utiliser une variable commune à plusieurs fichiers sources. Dans ce cas, il est indispensable que le compilateur comprenne que deux variables portant le même nom mais déclarées dans deux fichiers différents correspondent en fait à un seul objet. Pour cela, la variable doit être déclarée une seule fois de manière classique. Cette déclaration correspond à une définition dans la mesure où le compilateur réserve un espace-mémoire pour cette variable. Dans les autres fichiers qui l'utilisent, il faut faire une référence à cette variable, sous forme d'une déclaration précédée du mot-clef extern. Contrairement aux déclarations classiques, une déclaration précédée de extern ne donne pas lieu à une réservation d'espace mémoire.

Ainsi, pour que les deux fichiers sources main.c et produit.c partagent une variable entière x, on peut définir x dans produit.c sous la forme

int x;

et y faire référence dans main.c par

extern int x;

7.3 L'utilitaire `make`

Losrqu'un programme est fragmenté en plusieurs fichiers sources compilés séparemment, la procédure de compilation peut devenir longue et fastidieuse. Il est alors extrèmement pratique de l'automatiser à l'aide de l'utilitaire make d'Unix. Une bonne utilisation de make permet de réduire le temps de compilation et également de garantir que celle-ci est effectuée correctement.

7.3.1 Principe de base

L'idée principale de make est d'effectuer uniquement les étapes de compilation nécessaires à la création d'un exécutable. Par exemple, si un seul fichier source a été modifié dans un programme composé de plusieurs fichiers, il suffit de recompiler ce fichier et d'effectuer l'édition de liens. Les autres fichiers sources n'ont pas besoin d'être recompilés.

La commande make recherche par défaut dans le répertoire courant un fichier de nom makefile, ou Makefile si elle ne le trouve pas. Ce fichier spécifie les dépendances entre les différents fichiers sources, objets et exécutables. Il est également possible de donner un autre nom au fichier Makefile. Dans ce cas, il faut lancer la commande make avec l'option -fnom_de_fichier.

7.3.2 Création d'un `Makefile`

Un fichier Makefile est composé d'une liste de règles de dépendance de la forme :

cible: liste de dépendances
 <TAB> commandes UNIX

La première ligne spécifie un fichier cible, puis la liste des fichiers dont il dépend (séparés par des espaces). Les lignes suivantes, qui commencent par le caractère TAB, indiquent les commandes Unix à exécuter dans le cas où l'un des fichiers de dépendance est plus récent que le fichier cible.

Ainsi, un fichier Makefile pour le programme effectuant le produit de deux entiers peut être

## Premier exemple de Makefile

prod: produit.c main.c produit.h
        gcc -o prod -O3 produit.c main.c

prod.db: produit.c main.c produit.h
        gcc -o prod.db -g -O3 produit.c main.c

L'exécutable prod dépend des deux fichiers sources produit.c et main.c, ainsi que du fichier en-tête produit.h. Il résulte de la compilation de ces deux fichiers avec l'option d'optimisation -O3. L'exécutable prod.db utilisé par le débogueur est, lui, obtenu en compilant ces deux fichiers avec l'option -g nécessaire au débogage. Les commentaires sont précédés du caractère #.

Pour effectuer la compilation et obtenir un fichier cible, on lance la commande make suivie du nom du fichier cible souhaité, ici

make prod

make prod.db

Par défaut, si aucun fichier cible n'est spécifié au lancement de make, c'est la première cible du fichier Makefile qui est prise en compte. Par exemple, si on lance pour la première fois make, la commande de compilation est effectuée puisque le fichier exécutable prod n'existe pas :

% make
gcc -o prod -O3 produit.c main.c

Si on lance cette commande une seconde fois sans avoir modifié les fichiers sources, la compilation n'est pas effectuée puisque le fichier prod est plus récent que les deux fichiers dont il dépend. On obtient dans ce cas :

% make
make: `prod' is up to date.

Le Makefile précédent n'utilise pas pleinement les fonctionnalités de make. En effet, la commande utilisée pour la compilation correspond en fait à trois opérations distinctes : la compilation des fichiers sources produit.c et main.c, qui produit respectivement les fichiers objets produit.o et main.o, puis l'édition de liens entre ces deux fichiers objet, qui produit l'exécutable prod. Pour utiliser pleinement make, il faut distinguer ces trois étapes. Le nouveau fichier Makefile devient alors :

## Deuxieme exemple de Makefile

prod: produit.o main.o
        gcc -o prod produit.o main.o
main.o: main.c produit.h
        gcc -c -O3 main.c
produit.o: produit.c produit.h
        gcc -c -O3 produit.c

Les fichiers objet main.o et produit.o dépendent respectivement des fichiers sources main.c et produit.c, et du fichier en-tête produit.h. Ils sont obtenus en effectuant la compilation de ces fichiers sources sans édition de liens (option -c de gcc), et avec l'option d'optimisation -O3. Le fichier exécutable prod est obtenu en effectuant l'édition de liens des fichiers produit.o et main.o. Lorsqu'on invoque la commande make pour la première fois, les trois étapes de compilation sont effectuées :

% make
gcc -c -O3 produit.c
gcc -c -O3 main.c
gcc -o prod produit.o main.o

Si l'on modifie le fichier produit.c, le fichier main.o est encore à jour. Seules deux des trois étapes de compilation sont exécutées :

% make
gcc -c -O3 produit.c
gcc -o prod produit.o main.o

De la même façon, il convient de détailler les étapes de compilation pour obtenir le fichier exécutable prod.db utilisé pour le débogage. Le fichier Makefile devient alors :

## Deuxieme exemple de Makefile

# Fichier executable prod
prod: produit.o main.o
        gcc -o prod produit.o main.o
main.o: main.c produit.h
        gcc -c -O3 main.c
produit.o: produit.c produit.h
        gcc -c -O3 produit.c

# Fichier executable pour le debuggage prod.db
prod.db: produit.do main.do
        gcc -o prod.db produit.do main.do
main.do: main.c produit.h
        gcc -o main.do -c -g -O3 main.c
produit.do: produit.c produit.h
        gcc -o produit.do -c -g -O3 produit.c

Pour déterminer facilement les dépendances entre les différents fichiers, on peut utiliser l'option -MM de gcc. Par exemple,

% gcc -MM produit.c main.c
produit.o: produit.c produit.h
main.o: main.c produit.h

On rajoute habituellement dans un fichier Makefile une cible appelée clean permettant de détruire tous les fichiers objets et exécutables créés lors de la compilation.

clean:
        rm -f prod prod.db *.o *.do

La commande make clean permet donc de ``nettoyer'' le répertoire courant. Notons que l'on utilise ici la commande rm avec l'option -f qui évite l'apparition d'un message d'erreur si le fichier à détruire n'existe pas.

7.3.3 Macros et abbréviations

Pour simplifier l'écriture d'un fichier Makefile, on peut utiliser un certain nombre de macros sous la forme

nom_de_macro = corps de la macro

Quand la commande make est exécutée, toutes les instances du type $(nom_de_macro) dans le Makefile sont remplacées par le corps de la macro. Par exemple, on peut définir une macro CC pour spécifier le compilateur utilisé (cc ou gcc), une macro PRODUCTFLAGS pour définir les options de compilation utilisées pour générer un fichier produit, une macro DEBUGFLAGS pour les options de compilation utilisées pour générer un fichier produit pour le débogage... Le fichier Makefile suivant donne un exemple :

## Exemple de Makefile avec macros

# definition du compilateur
CC = gcc
# definition des options de compilation pour obtenir un fichier .o
PRODUCTFLAGS = -c -O3
# definition des options de compilation pour obtenir un fichier .do
DEBUGFLAGS = -c -g -O3 

# Fichier executable prod
prod: produit.o main.o
        $(CC) -o prod produit.o main.o
main.o: main.c produit.h
        $(CC) $(PRODUCTFLAGS) main.c 
produit.o: produit.c  produit.h
        $(CC) $(PRODUCTFLAGS)  produit.c

# Fichier executable pour le debuggage prod.db
prod.db: produit.do main.do
        $(CC) -o prod.db produit.do main.do
main.do: main.c produit.h
        $(CC) -o main.do $(DEBUGFLAGS) main.c
produit.do: produit.c produit.h
        $(CC) -o produit.do $(DEBUGFLAGS) produit.c

La commande make produit alors

% make 
gcc -c -O3  produit.c
gcc -c -O3 main.c 
gcc -o prod produit.o main.o

Cette écriture permet de faciliter les modifications du fichier Makefile : on peut maintenant aisément changer les options de compilation, le type de compilateur...

Un certain nombre de macros sont prédéfinies. En particulier,

$@ désigne le fichier cible courant :
$* désigne le fichier cible courant privé de son suffixe :
$< désigne le fichier qui a provoqué l'action.

Dans le Makefile précédent, la partie concernant la production de main.do peut s'écrire par exemple

main.do: main.c produit.h
        $(CC) -o $@ $(DEBUGFLAGS) $<

7.3.4 Règles générales de compilation

Il est également possible de définir dans un Makefile des règles générales de compilation correspondant à certains suffixes. On peut spécifier par exemple que tout fichier .o est obtenu en compilant le fichier .c correspondant avec les options définies par la macro PRODUCTFLAGS. Pour cela, il faut tout d'abord définir une liste de suffixes qui spécifient les fichiers cibles construits à partir d'une règle générale. Par exemple, avant de définir des règles de compilation pour obtenir les fichiers .o et .do, on écrit :

.SUFFIXES: .o .do

Une règle de compilation est ensuite définie de la façon suivante : on donne le suffixe du fichier que make doit chercher, suivi par le suffixe du fichier que make doit produire. Ces deux suffixes sont suivis par :; puis par une commande Unix (définie de la façon la plus générale possible). Les règles de production des fichiers .o et .do sont par exemple :

# regle de production d'un fichier .o
.c.o:; $(CC) -o $@ $(PRODUCTFLAGS) $<
# regle de production d'un fichier .do
.c.do:; $(CC) -o $@ $(DEBUGFLAGS)  $<

Si les fichiers .o ou .do dépendent également d'autres fichiers, il faut aussi spécifier ces dépendances. Ici, il faut préciser par exemple que ces fichiers dépendent aussi de produit.h. Le fichier Makefile a donc la forme suivante :

## Exemple de Makefile 

# definition du compilateur
CC = gcc
# definition des options de compilation pour obtenir un fichier .o
PRODUCTFLAGS = -c -O3
# definition des options de compilation pour obtenir un fichier .do
DEBUGFLAGS = -c -g -O3 

# suffixes correspondant a des regles generales
.SUFFIXES: .c .o .do
# regle de production d'un fichier .o
.c.o:; $(CC) -o $@ $(PRODUCTFLAGS) $<
# regle de production d'un fichier .do
.c.do:; $(CC) -o $@ $(DEBUGFLAGS)  $<

# Fichier executable prod
prod: produit.o main.o
        $(CC) -o prod produit.o main.o
produit.o: produit.c produit.h
main.o: main.c produit.h

# Fichier executable pour le debuggage prod.db
prod.db: produit.do main.do
        $(CC) -o prod.db produit.do main.do
produit.do: produit.c produit.h
main.do: main.c produit.h

clean:
        rm -f prod prod.db *.o *.do

Categories:

reading

Tuesday, February 5, 2013