1 - Amiga Magazine Online

Tipi e polimorfismo
Abbiamo detto che le macro presenti nel file 1iste.h ser-
vono per facilitare l'uso delle funzioni di Exec, in partico-
lare per quanto riguarda il cast sui tipi. È importante no-
tare che la scelta di operare in questo modo ha una certa
base teorica, anche se può produrre in pratica dei risulta-
ti dannosi. Infatti basta riflettere un attimo per rendersi
conto che le operazioni che si compiono sulle liste, sia
quelle descritte fin qui sia altre che potrebbero essere im-
plementate, come il calcolo del numero di elementi nella
lista, non dipendono dal tipo degli elementi contenuti.
Questa caratteristica, che non riguarda solo le liste, ma
anche le altre strutture contenitore (code, stack, ecc.) è
ben nota con vari nomi in diversi linguaggi di program-
mazione: polimorfismo parametrico in ML e Miranda,
package generici in ADA, template in C++.
In tutti questi linguaggi il polimorfismo parametrico (da
non confondere con il polimorfismo per inclusione, che
è collegato alla ereditarietà nei linguaggi object-oriented),
cioè la capacità di uno stesso oggetto di assumere forme
diverse pur mantenendo una sua "identità", è però realiz-
zato in modo che il controllo sui tipi avverta il program-
matore in caso di eventuali errori.
Invece in C, ricorrendo ai cast come abbiamo fatto nelle
macro, si aggira il controllo sui tipi, facendo credere al
compilatore che in una certa zona di memoria si trovi un
certo tipo di struttura.
Se abbiamo fatto tutto con cura, non ci sarà alcun pro-
blema, ma in caso di disattenzioni il compilatore non ci
darà alcun messaggio di errore, mentre avremo compor-
tamenti spiacevoli (guru) del nostro programma durante
l'esecuzione.
Utilizzando le macro si dovrà quindi fare attenzione a
non invertire l'ordine dei parametri, a utilizzare le struct
List e Node se si intende servirsi di Enqueue e FindName
e soprattutto, ci si dovrà ricordare di inserire come primo
campo degli elementi di lista da noi definiti una struct
Node o MinNode.
Liste o vettori?
Prima di concludere questo articolo, è giusto mettere a
confronto le due alternative, per evitare di comprare a
scatola chiusa. i punti a favore delle liste sono: capacità
di crescere e regredire dinamicamente; possibilità per gli
elementi di risiedere ovunque in memoria, dal momento
che sono i puntatori a mantenere la coesione della strut-
tura dati per cui non c'è alcun vincolo di adiacenza, co-
me accade invece per i vettori; nessuna necessità di pre-
vedere in anticipo il numero di elementi da memorizzare
e quindi di allocare più memoria di quanta se ne utilizza
effettivamente. Tutto ciò può essere riassunto nello slo-
gan: maggiore flessibilità.
I punti a sfavore sono non meno importanti: ogni ele-
mento inserito in lista occupa almeno 8 byte in più, per
tenervi i due puntatori, rispetto allo stesso elemento inse-
rito in un vettore; i byte diventano poi 14 se usiamo la
struct Node; inoltre non è possibile accedere direttamen-
te a un certo elemento della lista che non sia quello di
testa o di coda: la lista va scandita elemento per elemen-
to fino a raggiungere quello che ci interessa! Lo slogan a
favore dei vettori è quindi: maggiore efficienza.
Per finire, il programma di esempio presente su disco
può essere lanciato sia da CL1 che da Workbench: in
questo caso clickate sul gadget zoom prima di iniziare gli
esperimenti; l'interfaccia utente è ridotta al minimo.
Come esercizio potreste estendere questo esempio in
modo da utilizzare anche Enqueue e FindName. I più av-
venturosi e tenaci potrebbero invece cercare di realizzare
liste di liste oppure liste contenenti elementi non dello
stesso tipo, ma ai quali è possibile applicare una stessa
funzione, come una procedura di stampa.
A