Newsgroup: it.comp.lang.c++
Titolo: Visibilità delle variabili in grossi progetti

Sto realizzando un'applicazione in C++ abbastanza grossa (per me!) e quindi
con tanti file .h e .cpp.
Ho la necessità di definire delle variabili globali e ho pensato di creare
un file global.h con le dichiarazioni delle variabili (es int x,y ...) da
includere in tutti i file in cui mi servono. E fin qui tutto Ok. Il problema
sorge quando eseguo il link del progetto che mi si generano una serie di
warning del tipo:
Pippo.obj : error LNK2005: "int  variabile" (?variabile@@3HA) already
defined in Pluto.obj
Per far si che l'eseguibile venga comunque generato utilizzo l'opzione
/FORCE del linker (VC++6/MFC).
Dove dovrei mettere quelle variabili??
Premetto che ho anche provato a includere il file global.h solo nel file
stdafx.h ma le cose non migliorano.
Grazie.
emanuele
--
~~~~~~~~~~~~~~~~>))))°>~~~~~~~~~~~~~~~~
b0nu$ - 
bo...@numerica.it
Linux User Group - 
http://www.lugbs.linux.it
Assembly page - 
http://wurstel.ing.unibs.it/~bonus
ICQ - 3627899
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 includere in tutti i file in cui mi servono.
Le definizioni devono essere presenti in un solo sorgente. In tutti gli
altri devono apparire le corrispondenti dichiarazioni "extern".
EMG

 
In genere le variabili globali si definiscono in un unico file .cpp e si
dichiarano extern in un file .h, da includere dove serve.
Detto questo, lascio ad altri il compito di spiegarti perche' e' meglio
evitare l'uso di variabili globali.
Ciao,
Nicola

 un file global.h con le dichiarazioni delle variabili (es int x,y ...) da
Fossero solo dichiarazioni, andrebbe anche bene (per quanto "bene"
possano mai andare le variabili globali, cioe`, non molto).  Da quanto
scrivi pare invece che tu abbia usato delle *DEFINIZIONI*, violando
quindi (con molteplici include) la one-definition-rule.
Usa quindi nel .h delle DICHIARAZIONI, *NON* delle definizioni:
    extern int x;
    extern int y;
eccetera;
le definizioni corrispondenti, cioe`:
    int x;
    int y;
eccetera, mettile invece in un .cpp a tua scelta (ad esempio, puoi
definire apposta un sorgente "globali.cpp" che non ha altro che
queste robe).
Alex


~~~~~~~~~~~~~~~~~
MAINARDI Gianfranco
Burago di Molgora (MI)
Italia
Email : 
main...@libero.it
ICQ# number : 31334916
~~~~~~~~~~~~~~~~~

 
Una volta facevo anch'io cosi'. Ora preferisco distinguere tra
interfaccia e implementazione mettendo le "definizioni" (ovvero le
istruzioni che provocano l'allocazione di memoria) in file di
implementazione (di solito .cpp,.cxx,.C,ecc) e mettendo le
"dichiarazioni" (ovvero le istruzioni che indicano la disponibilita' di
una variabile,funzione,ecc.) in un file di interfaccia (ovvero .h).
Cioe' il file .cpp contiene la fornitura concreta di servizi, mentre il
file .h li pubblicizza.
Ciao,
Nicola

evitare l'uso di variabili globali.
Beh..quantomeno bisogna cercare di ridurle al minimo indispensabile.
Il Ghenio

defined in Pluto.obj
E posso capire bene il motivo dell'errore. Creando un file 'h' con la
dichiarazione della variabili globali e includendolo in tutti i moduli
del tuo programma é come se quelle variabili tu le dichiarassi più
volte.Fossi in te proverei a definire le variabili solo nel file cpp
principale,e ridichiararle come variabili extern all'interno di ogni
tuo file include.Per far questo appoggiati pure al tuo file
'global.h'. Ad ogni modo,a mio avviso, per i progetti grossi sarebbe
meglio implementare il programma ad oggetti, eliminando cosi'(o
quantomeno riducendo drasticamente)il numero di variabili globali
all'interno del programma che alla fine rischiano di creare una grossa
confusione e nel peggiore dei casi di saturare il "Data Segment".
Il Ghenio


No, no, eliminarle del tutto. Io non amo nemmeno le variabili statiche
visibili solo nel file dove sono definite (altri possono spiegarti dove
e come possono essere utili), in quanto preferisco in genere definire
membri statici; in nessun caso pero' trovo conveniente avere variabili
globali in quanto tali. Di solito si riesce a costruire loro intorno
della funzionalita' e quindi consentire l'accesso a questa funzionalita'
altraverso funzioni libere o metodi statici.
Ciao,
Nicola