Newsgroup: it.comp.lang.c++
Titolo: Dubbio su scope di una variabile

Secondo il libro Stroustrup ( e forse anche secondo lo standard), lo scope
di una variabile è limitato al blocco in cui la variabile è definita.
Quindi se una variabile è definita in un ciclo for, il suo scope è limitato
al blocco che contiene il codice eseguito nel ciclo.
Il seguente codice quando viene compilato su sgi non dà errore:
for (int i=0;i<10;++i)
    ;
for (int i=0;i<10;++i)
    ;
Mentre in ambiente Microsoft Visual C++(5 e 6), dà errore a causa della
ridefinizione di i. L'help di MS è poco chiaro riguardo lo scope di una
variabile.
Esiste un modo per far compilare a MS come Stroustrup comanda?
Grazie per i chiarimenti.
Alessandro Chiarini

ridefinizione di i.
Prima non era così, quindi VC++ che è pre-standard si comporta in modo
"sbagliato", in VC++.Net puoi obbligare il compilatore a comportarsi
im modo corretto cun un flag.
Una soluzone semplice è usare:
#define for if(0);else for
-- 
Marco Barisione (ICQ 84277092)

for (int i=0;i<10;++i)
E' un classico...una non conformità del VC++ su cui ancora molti
cascano.
Secondo lo standard la 'i' dei due for é differente, in quanto le due
variabili "muoiono" con la fine del ciclo, ma il VC++ che é rimasto
indietro si comporta come i compilatori vecchi, percui considera 'i'
ridefinita.
Il Ghenio
---------
// TODO: Place your ass here

 #define for if(0);else for
Si, poi quando ti trovi a dover lavorare sul codice di qualcuno che ha 
scritto queste cose ti vengono gli attacchi di bile... 8///
-- 
Luc.

scritto queste cose ti vengono gli attacchi di bile... 8///
Io sono innocente, č una soluzione proposta da Andrea Griffini!
Comunque se tu dovessi modificare il codice scritto per un compilatore
piů conforme allo standard per questo aspetto cosa faresti? Modifichi
tutti i for?



Effettivamente forse scriverei la macro come:
#define FOR_PER_COMPILATORI_STUPIDI if(0);else for
e poi sostituirei tutti i for, in modo da rendere evidente la presenza
del workaround e semplificarle una eventuale futura rimozione.
Ciao,
Nicola

scritto queste cose ti vengono gli attacchi di bile... 8///
Che cos'ha di brutto ? Io da quando ho letto questo
giochetto lo uso spesso. In ogni caso a toglierlo ci
vuole un attimo quando MS si decidera' a risolvere la
cosa in modo ragionevole (in realta' VC++ ha una opzione
di compilazione -- disable extensions o qualcosa di simile --
solo che se la attivi non riesci piu' ad includere
windows.h; e scusate se e' poco).
Come anche aggiungo sempre #pragma warning(disable: 4786)
perche' altrimenti il codice che usa la libreria standard
fa diventare il compilatore isterico. Non e' una cosa bella
di sicuro che per fare la cosa piu' standard possibile MS
mi obblighi a usare cose non standard... ma non ci posso
fare nulla se a MS del C++ standard non frega un tubo!
Io fra l'altro non sono un tifoso del preprocessore, ma
se l'alternativa e' scrivere migliaia di linee di codice
non portabile, oppure orrendo (come consiglia Nicola)
oppure con cintura e bretelle (vedi aggiungere graffe che
racchiudono ogni for) non ho dubbi che sia meglio usare
un trucchetto.
Fra l'altro quale sarebbe il problema di quella #define ?
Andrea

del workaround e semplificarle una eventuale futura rimozione.
E in cosa consisterebbe la semplificazione ?
Andrea


Nel minor rischio di errori compiendo ricerca e sostituzione.
Ciao,
Nicola

Nel minor rischio di errori compiendo ricerca e sostituzione.
Ti ho perso....
Secondo te sostituire "#define for if(0); else for"
con una linea vuota in qualche .h (nel mio caso e'
se possibile un solo .h che cerca di raggruppare le
problematiche di portabilita') e' piu' rischioso che
dover sostituire qualcosa nell'utilizzo dei for (nel
mio caso direi la *maggioranza* dei for) nei file
.cpp di implementazione ?
Ho l'impressione che la razionalita' abbia
abbandonato questo thread...
Andrea

 .cpp di implementazione ?
Hai ragione, ero distratto. Resto pero' perplesso dall'applicazione di
workaround pressoche' invisibili all'interno del codice, soprattutto se
orientati ad aggirare bachi del compilatore. Per questo in generale
preferisco che le macro colpiscano il lettore, anche se in questo caso
probabilmente il gioco non vale la candela.
Ciao,
Nicola