Programmazione modulare in C

Programmazione modulare nel
linguaggio C
Paolo Bernardi
07EIPCH
AA 2008/09
Ing. Paolo Bernardi

Introduzione
– Non è possibile creare programmi di elevata
complessità lavorando con un unico file sorgente
• Lentezza di ricompilazione
• Difficile riuso di procedure
• Impossibile collaborare tra più programmatori
• Difficile tener traccia delle modifiche
– Occorre realizzare programmi distribuiti su più file
sorgenti
– Chiameremo tali programmi progetti multi-file o,
più semplicemente progetti.
2
Ing. Paolo Bernardi

Compilazione e Link
.c
Sorgente
C
Sorgente
C
Sorgente
C
Sorgente
Assembler
Compilatore Compilatore Compilatore
Assemblatore
.obj
Codice
oggetto
Codice
oggetto
Codice
oggetto
Codice
oggetto
.exe
Codice
eseguibile
Linker
Libreria
Libreria
.lib
3
Ing. Paolo Bernardi

Struttura del compilatore
Sorgente C
Analisi lessicale
Analisi sintattica
Analisi semantica
Generazione codice
indipendente HW
Ottimizzazione
Generazione codice binario
Ottimizzazione
Codice
oggetto
4
Ing. Paolo Bernardi

Modulo di Codice oggetto
– Contiene il codice binario corrispondente ad un
modulo C
– Contiene dei riferimenti esterni a funzioni e
variabili dichiarate in altri moduli
– Contiene funzioni e variabili utilizzabili da altri
moduli
– Uno ed un solo modulo nell’intero progetto
contiene il programma o funzione principale
• int main(void){…};
5
Ing. Paolo Bernardi

Modulo oggetto
Funzioni usate dal
modulo ma definite
altrove
strcmp
strcpy
6
stdout
Variabili usate dal
modulo ma definite
altrove
sort.c
sort.obj
Codice
binario
Funzioni definite nel
modulo, richiamabili
anche dall’esterno
inssort
cntsort
scambi
Variabili definite nel
modulo, utilizzabili
anche dall’esterno
Ing. Paolo Bernardi

Linker
Codice
oggetto
Codice
oggetto
Codice
oggetto
Codice
oggetto
Codice
oggetto
7
Ing. Paolo Bernardi

Modularità
• Ciascun modulo in C:
– Definisce alcune funzioni “private”
– Definisce alcune funzioni “pubbliche”
– Definisce alcune variabili “private”
– Definisce alcune variabili “pubbliche”
– Chiama alcune funzioni “esterne”
– Usa alcune variabili “esterne”.
8
Ing. Paolo Bernardi

Chiamata di funzioni (I)
void InsertionSort(int A[], int n) ;
Funzione
pubblica
void InsertionSort(int A[], int n)
{
int i, j, key ;
/* … */
libreria.c
9
extern void InsertionSort(int A[], int n) ;
/* … */
int main(void)
{ int v[10] ;
/* … */
InsertionSort(v, 10) ;
client.c
/* … */
Ing. Paolo Bernardi

Chiamata di funzioni (II)
– Il modulo che esporta una funzione non deve fare
nulla di particolare
• in C, tutte le funzioni sono pubbliche cioè hanno classe
di memorizzazione automatica
• tranne nei casi in cui la loro dichiarazione sia preceduta
dalla parola chiave static (funzioni private)
– invocabili esclusivamente dal modulo che le definisce
– Il modulo che utilizza la funzione deve dichiararne
il prototipo (con la parola chiave extern)
– Il linker farà il collegamento.
10
Ing. Paolo Bernardi

Funzioni private
– Nel caso in cui un modulo definisca delle funzioni
che NON vuole esportare, nella definizione (non
nel prototipo) deve comparire la parola chiave
static.
void InsertionSort(int A[], int n) ;
void CancellaVettore(int A[], int n) ;
void InsertionSort(int A[], int n)
{ . . . }
static void CancellaVettore(int A[], int n)
{ . . . }
11
Ing. Paolo Bernardi

Variabili globali (I)
int n_elem ; client.c
double vett[MAX] ;
static int temp ;
extern int n_elem ; libreria.c
extern double vett[MAX] ;
/* … */
{ for(i=0; i

Variabili globali (II)
– Il modulo che esporta una variabile globale non
deve fare nulla di particolare: in C, tutte le variabili
globali sono pubbliche (per default)
– Il modulo che utilizza la variabile deve ri-definirla
con la parola chiave extern
– Se non si vuole esportare una variabile occorre
definirla con la parola chiave static
– Le variabili locali (alle procedure) non possono
essere condivise.
13
Ing. Paolo Bernardi

Problemi
– Le due dichiarazioni (nel modulo che esporta e
nei moduli che usano la funzione/variabile)
devono coincidere al 100%
int f( int x ) ;
Errore!
extern int f( double x );
14
int f(int x)
{ . . . }
libreria.c
int main(void)
{ . . .
y = f ( z ) ;
. . .}
client.c
Ing. Paolo Bernardi

Il ruolo degli header file
– Si possono utilizzare degli header file (file .h) per
raccogliere le definizioni extern di funzioni e
variabili pubbliche
– Il creatore del modulo che esporta le funzioni o
variabili crea un file .h
– Tutti i moduli che usano tali risorse esportate
includono i file .h (#include).
15
Ing. Paolo Bernardi

Esempio di header file (I)
void InsertionSort(int A[], int n) ;
extern int n_elem ;
extern double vett[MAX] ; sort.h
#include "sort.h" /* per controllo coerenza */
int n_elem ;
double vett[MAX] ;
sort.c
static int temp ;
void InsertionSort(int A[], int n)
{ . . . }
static void CancellaVettore(int A[], int n)
{ . . . }
16
Ing. Paolo Bernardi

Esempio di header file (II)
void InsertionSort(int A[], int n) ;
extern int n_elem ;
extern double vett[MAX] ; sort.h
#include "sort.h" /* per importare dichiarazioni */
int main(void)
{ int v[10] ;
/* … */
client.c
InsertionSort(v, 10) ;
/* … */
for(i=0; i

Note
– Ciascun modulo solitamente esporta alcune
funzioni o variabili, e ne importa altre
– È sempre bene che ciascun modulo includa
anche il proprio header file
– Conviene limitare al minimo il numero di variabili
condivise
– Includere anche le #define nei file .h
– È buona norma raccogliere tra loro gruppi di
moduli correlati per funzionalità
• possono condividere l’header file.
18
Ing. Paolo Bernardi

Inclusione multipla di librerie
• L’uso delle librerie può originare problemi in
fase di compilazione
• Se 2 moduli differenti di uno stesso progetto
includono la stessa libreria, il compilatore
– rileverà variabili e funzioni definite 2 volte
– interromperà il processo di compilazione del
progetto.
19
Ing. Paolo Bernardi

Inclusione multipla di librerie (cont.)
20
• Utilizzo di direttive per il compilatore
• Alla prima inclusione la variabile di compilazione MNEMONICO
non è ancora stata definita, quindi il file viene linkato
regolarmente
• Alla seconda, essendo MNEMONICO già stato definito, il
contenuto del file non viene ricaricato.
#ifndef MEMONICO
#define MEMONICO
void InsertionSort(int A[], int n) ;
extern int n_elem ;
extern double vett[MAX] ;
#endif
Identificatore univoco all’interno
del progetto, ovvero 1
MNEMONICO differente per file
sort.h
Ing. Paolo Bernardi

Filosofia della
programmazione multi-file
21
• Il linguaggio C mette a disposizione del
programmatore pochi semplici strumenti che,
accompagnati ad una opportuna e necessaria
disciplina di programmazione, consentono di gestire
in maniera ottimale progetti software di grandi
dimensioni [Luca Durante]
• Il kernel di Linux, circa 100 MB di sorgente,
suddiviso in circa 8000 di file sorgenti, è scritto in
massima parte in C (e in assembler la restante
parte) da centinaia di programmatori sparsi per il
mondo, che spesso non si sono neppure mai
incontrati.
Ing. Paolo Bernardi

Sviluppo di grandi progetti
• Necessita di organizzazione e sincronismo
• Definizione delle interfacce, cioè del
contenuto degli header file
– Per ciascuna funzione sono specificate le
funzionalità
• Ripartizione delle risorse
– 1 modulo di libreria = 1 programmatore.
22
Ing. Paolo Bernardi

Sviluppo di grandi progetti (cont.)
23
• Uso dei cosiddetti repository
– 1 versione gold del progetto (obbligatoriamente
funzionante) memorizzata su un server remoto
– N versioni locali a disposizione dei singoli programmatori
per valutare le soluzioni sul modulo di propria competenza
• Il programmatore impegnato nello sviluppo proprio
modulo
– Scarica in locale l’intero progetto gold (update)
– Lo modifica e valuta l’efficacia del suo intervento
– Se soddisfacente, lo carica sul server all’interno del
progetto gold (commit)
• È mantenuta la “storia” dei commit.
Ing. Paolo Bernardi

Sviluppo di grandi progetti (cont.)
Implementazione
LOCAL
LOCAL
Update
Commit
Update
Commit
24
Definizione delle
specifiche
GOLD
Ing. Paolo Bernardi