Newsgroup: it.comp.programmare.win32
Titolo: Variabili globali

Ho iniziato da poco a programmare con le API di Windows e ho un piccolo
dubbio. Sembra che sia necessario fare un grande uso di variabili globali o
statiche. Vero? Dato che sono abituato a rispettare certi criteri di
programmazione strutturata vorrei sapere se esiste un modo non troppo
artificioso per evitare il loro uso.
Marco

Dipende... cosa intendi per "programmazione strutturata"? In ogni caso se
vuoi programmare in maniera più pulita, invece di usare il C e le API
dovresti usare qualcos'altro, ad esempio un framework come MFC o VCL o un
ambiente come Visual Basic. In realtà la tua applicazione sembrerà pulita,
senza variabili globali eccetera, ma sotto l'implementazione, a tua
insaputa, continueranno ad esserci tutti i particolari "sporchi". Pertanto,
se mi permetti, credo che dovresti preoccuparti un po' meno dello stile di
programmazione per concentrarti sulla qualità di programmazione. Il fatto
che vangano fra loro associati è, secondo me, una grande bufala. D'altronde
anche la programmazione più rigorosa viene tramutata in un ammasso
disordinato di JMP, JNZ, POP, PUSH e così via. Dal mio punto di vista, la
bellezza estetica del codice va ricercata altrove, e nello specifico nella
concisione (cosa c'è di più bello di un while(*p++ = *q++); ?)
Siamo comunque più nel campo della filosofia che della tecnologia, e perciò
si rischia di essere un po' OT (ma non credo che quelli di
it.cultura.filosofia accetterebbero questo tread).
Bye,
Lorenzo

,

Le variabili globali e statiche non sono tutto quel male che
si vorrebbe attribuire loro.
Mantenere hInstance in una variabile globale, al posto di richiederlo
ogni volta che serve al sistema e' ragionevole e lecito.
In fondo, se tu dovessi creare una classe per astrarre in concetto
di applicazione, finiresti per mettere una variabile membro di classe,
magari publica on con funzione inline GetInstance().
Ovviamente la tua classe la istanzieresti a scope globale, e sarebbe
lo stesso di avere la variabile globale, oppure la istanzieresti
runtime, ed in quel caso avresti la tua variabile sull'heap
del processo corrente. Ma un oggetto che vive per tutta la durata
del programma ed istanziato sull'heap non ha molto senso.
Una variabile globale o una classe a scope globale delegano al
linker e al loader il compito di riservare memoria sul tuo spazio
di indirizzamento.
Mantenere una tua variabile globale di sincronizzazione, magari e'
meno bello, peche' dovresti trovare un metodo piu' protetto per
svolgere lo stesso compito.
Per quanto riguarda le variabili statiche, non c'e' verso di
mantenere lo stato di qualcosa attraverso la costruzione e la
distruzione dello stack che avviene ogni volta che una funzione viene
chiamata.
Se non vuoi usare le facility offerte dal linguaggio e dal compilatore
per mantenere lo stato, allora crea una classe (necessariamente
unica per lo stato che vuoi mantenere) e crea tante funzioni
di accesso e modifica dello stato.
Anche in questo caso: le funzioni inline ti aiutano ad avere
efficienza nell'accedere alle variabili, ma ti rimane il problema
di "creare la classe" e di farla vedere a tutti i moduli che
ne hanno bisogno.
Sent via Deja.com 
http://www.deja.com/
Share what you know. Learn what you don't.

statiche. Vero?
No, non ti preoccupare...
Qualunque linguaggio (strutturato) tu usi, puoi evitare tranquillamente 
l'uso di variabili globali. In realta` di globale nelle API ci sono solo
delle costanti predefinite che assumono un ruolo ben preciso
all'interno del sistema e che chiaramente fanno parte della sua
interfaccia, ma essendo costanti non creano i problemi che si
avrebbero con delle variabili.
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

concisione (cosa c'è di più bello di un while(*p++ = *q++); ?)
Quanto tempo impieghi a capire cosa (non quanto) produce l'espressione
int a =1;
int b = 0;
int c = 2;
a++ << ++c & b
L'esempio non e` molto difficile, ma non e` piu` comprensibile scrivere
a++;
++c;
(a << c) & b;
Tanto piu` che il compilatore sa ottimizzare ugualmente?
Ricorda poi che nel mondo del lavoro, chi esegue la manutenzione
non e` necessariamente l'autore del programma e non ha necessariamente
le stesse conoscenze. Inoltre le software house difficilmente 
preferiscono ricominciare da capo ogni qual volta bisogna apportare
modifiche al codice.
Mi pare che tu sia un programmatore C++, in tal caso ti consiglio
di leggere
"C++ manuale di stile" di C. Pescio, ed. infomedia (costa veramente 
poco ed e` molto ben fatto)
e poi potresti continuare con
"Effective C++" e "More effective C++" di S. Meyers, Addison Wesley


 concisione (cosa c'è di più bello di un while(*p++ = *q++); ?)


 di leggere
Argh! Cosa mi tocca sentire!!! Io ABORRO il C++, anche se di tanto in tanto
lo uso per forza maggiore (e poi il C++Builder fa risparmiare lotti di tempo
con la UI).
Bye,
Lorenzo

 programma non lo legge nessuno...) !
...infatti non uso mai goto e sempre i commenti, anche se di tanto in tanto
ammetto eccezioni.
Bye,
Lorenzo

con la UI).
Vale sempre il consiglio di prima (il testo di C. Pescio poi costa solo
36.000 lire per circa 288 pagine).
Tutto questo comunque senza voler fare una guerra di religione, le
eccezioni sono sempre possibili, ma i fatti dimostrano che le eccezioni
devono rimanere tali.


 devono rimanere tali.
Ah, credevo fosse una guerra di religione, ma adesso mi accorgo che è
semplicemente uno jihad. Scherzi a parte, vedi, il fatto è che il codice,
indipendentemente dal modo in cui è stato scritto prima della compilazione,
è codice binario. Nonostante tutti i nostri tentativi di astrazione, non
resta altro che un ammasso di istruzioni elementari che manipolano stati
elettrici alti o bassi nei registri dei processori. Questo non vuol dire che
noi dobbiamo lavorare a questo livello, ma semplicemente che sarebbe meglio
evitare di far finta che non esista. Una ricerca di un'astrazione troppo
spinta è, a mio avviso, un errore. Infatti, scomodando i nostri avi, in
medio stat virtus. Cosa porta un'astrazione troppo elevata? A complicazioni
inutili e a pesanti overhead. La storiella che tanto i processori di oggi
sono sufficientemente potenti da permetterci il lusso di dimenticare
l'ottimizzazione, lascia davvero il tempo che trova. Perché, infatti, su una
macchina che va a 400 MHz aprire una finestra della shell di Win98 richiede
un'attesa? Aprire la stessa finestra in Win95 su una macchina inferiore è
istantaneo, è praticamente contemporaneo alla pressione dei tasti "Windows"
ed "E". In Win98 invece ci vuole qualche frazione di secondo. Un'inezia
forse, ma è estesa. La causa è che la shell di Win98 non fa la shell, ma fa
da contenitore per un oggetto che può variare: una cartella di file, un file
html, un documento di Word. Io uso questa shell perché è comodissima. Ma, ne
sono certo, era possibile ottenere tutto questo a velocità superiori, senza
complicarsi la vita.
Mmh... forse non è chiaro ciò che voglio dire... fammi sapere.
Bye,
Lorenzo
PS: volevo curiosare sulla tua home page ma il server mi dice che non ho
l'autorizzazione a visualizzarla. È normale?

l'autorizzazione a visualizzarla. È normale?
Assolutamente no! Attualmente ci sono dei lavori in corso al centro di 
calcolo per cui si possono verificare disguidi temporanei, ma il
discorso dei diritti e` molto strano... verifichero`!
