Costanti e variabili: qual’è la vera differenza?
Domenica 2 Dicembre, 2007Sembra ovvio, ma ad alcuni sfugge la sottile differenza tra costanti e variabili in un linguaggio di programmazione. Le costanti, dal nome stesso, non cambiano il loro valore durante il ciclo di un programma, mentre le variabili possono farlo! Tuttavia, spesso, capita di usare variabili al posto di costanti senza rendersene conto, anche perchè questo non impatta la logica di una applicazione. Nonostante questo, la differenza tra costanti e variabili c'è ed emerge tutta nel momento della compilazione, dove la costante gioca un ruole sicuramente più performante.
Chi viene dalla programmazione Assembly o C conosce bene la differenza tra costanti e variabili, soprattutto perchè, sia in Assembly che in C, le costanti rivestono un ruolo più da MACRO. Per MACRO indendo una "parte di codice" che viene etichettata e sostituita all'interno del codice nel momento della compilazione. Il compilatore, per farla breve, esegue una sorta di find..replace (trova e sostituitsci) nel codice ogni volta che incontra una costante.
Immaginiamo di scrivere in C la seguente semplice porzione di codice:
-
int a = 5;
-
int b = 3;
-
int c;
-
c = a + b;
Sia a che b sono indicate come variabili in questo caso. In C, infatti, le costanti si definiscono con la keyword #define. Notiamo subito che sia a che b sono state definite come int. Già qui si può operare una prima ottimizzazione. Se sappiamo che la nostra variabile a non supererà mai un determinato valore, è bene dichiararla in modo appropriato e non usare tipi dati a caso. Alcuni sviluppatori non si preoccupano affatto di dichiarare correttamente i tipi, pensando che questo non influisca sulle performace! Sbagliato! In alternativa è accettabile che la prima stesura del codice non implichi questo livello di dettaglio. È comunque buona regola, durante il processo di sviluppo, rivedere il codice e verificare i tipi dati.
Comunque sia, in un Assembly della famiglia Motorola, ad esempio, come il mitico 68000, il nostro codice verebbe compilato (senza ottimizzazioni) in una specie di:
-
move.l #5, d0 ; int a
-
move.l #3, d1 ; int b
-
move.l d1,d2 ; int c - foo
-
add.l d0,d2 ; risultato in d2 ovvero c
oppure:
-
move.l #5, d0 ; int a
-
move.l #3, d1 ; int b
-
move.l d0,d1 ; risultato in d1...
Il compilatore, per quanto intelligente, fatica nelle ottimizzazioni, quindi scrivere il codice con le giuste keyword può solo aiutarlo a migliorare l'output compilato. Nel nostro caso se il valore 5 è una costante non è conveniente usare una variabile intera, in quanto il compilatore, giustamente, considerando la variabile variabile, appunto, predisponde un intero per contenere il semplice valore di 5; che in binario è 101, cioè occupa 3 semplici bit (caso mai int è un 32bit o peggio un 53bit a doppia precisione a virgola mobile!!). Se avessimo scritto il codice in questo modo:
-
#define MIA_COSTANTE 5
-
-
int b = 3;
-
int c;
-
c = MIA_COSTANTE + b;
Il compilatore avrebbe saputo sin dall'inizio che MIA_COSTANTE, essendo costante, non muterà valore e quindi posso riservare meno spazio per trattarla. Nella pratica il codice Assembly diverebbe:
-
moveq #3, d0 ; la "q" indica una istruzione "quick", cioè che tratta valori compresi tra -128 e +127
-
; una istruzione "quick" prende meno tempo della CPU (4 cicli di clock in questo caso)
-
addq #5,d0 ; anche qui uso una istruzione "quick"
Quest'ultimo codice è estremamente più rapido e occupa meno byte. Quello che bisogna tenere a mente è che quando si dichiara una variabile l'ambiente si predispone per trattarla come tale, anche se i compilatori di oggi riescono a fare miracoli, eseguendo una serie di passaggi nel codice prima di compilare (alcuni compilatori, addirittura, eseguono una specie di simulazione del programma per ottimizzare al massimo la compilazione in codice macchina).
Una buona regola, quindi, è quella di dichiarare il giusto tipo per le nostre variabili, se tali sono. In alternativa usare le costanti, soprattutto se il linguaggio di programmazione che stiamo usando le prevede (come nel caso del nuovo Flash CS3).






















Lascia un commento