Newsgroup: it.comp.lang.c++
Titolo: Le variabili globali e l'IDE...

Spero di non far venire un'infarto secco ai puristi del linguaggio... :-D
Premessa:
- mi piace suddividere i miei progetti. Nel senso che uso diversi file .cpp 
e .h, ciascuno per il proprio argomento
- non uso abitualmente il C++, per cui potrei chiedere cose ovvie
Problema:
Esiste un modo semplice per dichiarare variabili "globali" a tutti i file?
Intendo dire...invece di dover dichiarare la variabile in uno degli .h, poi 
ri-dichiararla extern in tutti gli altri...esiste qualche direttiva che dica 
al compilatore "io questa la dichiaro qui, ma te ricordatela anche quando 
compili gli altri file?"
Oppure una qualche "estensione" del linguaggio tipica dell'ambiente di 
sviluppo? (VS6, nel mio caso)
Grazie...ciao!
P.S.: il metodo che ho chiesto sopra sarebbe il mio preferito...anche se in 
realta' ho la sensazione che basti creare un .h dove sono dichiarate extern 
tutte le variabili che voglio globali, dire al compilatore di includerlo 
sempre, e poi dichiarare le variabili dove piu' mi piace...

 sempre, e poi dichiarare le variabili dove piu' mi piace...
Esatto.
'Notte,
-- 
Matteo Settenvini
FSF Associated Member
Email : 
mat...@member.fsf.org
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(-) s+:- a-- C++ UL+++
P?>++ L+++>$ E+>+++ W+++ N++ o?
w--- O- M++ PS++ PE- Y+>++
PGP+++ t+ 5 X- R tv-- b+++ DI+
D++ G++ e h+ r-- y?
------END GEEK CODE BLOCK------


ma se anche uno definisce vere e proprie variabili in un file da 
includere molteplicemente (sia esso .H o .CPP poco m'importa), 
ma ha la cautela di usare il costrutto condizionale #infdef 
JUST_INCLUDED .... #define JUST_INCLUDED .... codice .... #endif
non è ugualmente sicura la definizione effettiva anche nei files 
da includere ?
ciao
Soviet_MArio


 Soviet_MArio



non discuto SE accada o meno, visto che non ho provato e tu 
probabilmente si .... ma perché ?
non capisco. La #infdef dovrebbe istanziare soltanto una volta 
quella variabile, no ?
Cioè, mi viene un dubbio .... quando cambia unità di 
compilazione (file) il PREPROCESSORE perde memoria delle defines 
delle unità precedenti ? ?
Se è così, allora ho capito la ragione
Se le ricorda, come cavolo fa a includere tre volte la data 
variabile ?
Spiegami questo dettaglio, che non so molto del comportamento 
del processore nell'assemblare vari files
ciao
Soviet_Mario


>>>> [...]

Esatto, ogni chiamata al frontend del compilatore, sia "gcc" o "g++" o
altro, provoca l'invocazione anche del preprocessore "cpp". Tuttavia, si
tratta di processi indipendenti tra di loro, che non possono mantenere
memoria delle variabili del preprocessore per molte ragioni, logiche, di
semplicità e di sicurezza.
La "#ifndef" non istanzia proprio niente. E' solo un "blocco
decisionale" per il preprocessore, che considera quello che sta entro
#ifndef e #endif SOLO se la variabile data non è definita.
Per esempio, potrei scrivere:
if( print() == true ) {
#ifdef __LINUX
  StampaSuGNULinux();
#elif __WIN_32
  StampaSuWindows();
#endif
}
Quello che fa il preprocessore, è "produrre il codice" che verrà
compilato, cioé sostituire le macro. Per esempio, "g++ -D__LINUX
file.cc" passerà alla fase di compilazione ignorando quanto concerne il
codice per __WINDOWS.
Quindi:
if( print() == true ) {
  StampaSuGNULinux();
}
Se vuoi scomporre i maggiori passi che il frontend al compilatore esegue
compilando un programma da solo un file, puoi ad esempio scrivere un
semplice "Hello World", magari con una stampa tra #ifdef, e poi:
g++ -E hello.cc > hello.ii  # preprocessore
g++ -S hello.ii             # verso assembler
g++ -c hello.s              # compilazione verso "codice macchina"
g++ -o hello hello.o        # linking
g++ è solo un frontend che si preoccupa di fare le cose giuste.
Scusate se con i termini non sono stato super preciso.


 Scusate se con i termini non sono stato super preciso.
ciao e grazie delle delucidazioni
Soviet_Mario

 sino al linking
Sono locali all'unità corrente di compilazione. Spesso si usano delle
regole nei Makefile (specie se usi gli autotools di *n?x) per ripeterle
ad ogni invocazione del preprocessore, ma questa è un'altra storia.
Recentemente GCC4 credo supporti anche la sintassi "@file" da riga di
comando per inserire un mucchio di definizioni (al posto di usare
-DMACRO="contenuto_macro").
Se la cosa ti interessa, si può approfondire su
it.comp.os.linux.development.
Alcune variabili al preprocessore sono inoltre disponibili di default, e
si possono usare nei propri programmi per assicurarsi della presenza di
alcune feature particolari. Puoi vedere quelle definite sul tuo sistema,
per esempio, con "touch temp && cpp -dM temp", il che torna spesso utile.
Scusa se ho dubitato di te quando ho detto che l'#ifndef non istanzia
proprio niente, ma mi è già capitato che qualcuno facesse confusione e
dicesse che macro come:
#define max(a,b) ((a)>(b) ? (a) : (b))
dichiaravano una funzione. Si vede che avevo attivato l'antipaticissimo
modo "-pedantic"... sorry. Non avertene a male. ;-)
Ciao,


no problem figurati, anzi grazie dei suggerimenti. ORa come ora 
uso windows, quindi mi documenterò se esistono alternative agli 
autotools che citi
ciao
CCCP++Mario


 CCCP++Mario
Cosa vorresti fare per essere piu' specifico? 
Tommaso
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
Credo che in windows la soluzione migliore sia utilizzare un IDE come
Visual Studio che fa tutto il lavoro.
Windows non ha mai avuto un bisogno particolare di strumenti per
assicurare la portabilità, visto che Microsoft è l'unico vendor del
sistema operativo e si adopera per mantenere una certa compatibilità tra
versioni diverse.
Questo cambia molto per i programmi del mondo Unix che devono scontrarsi
con centinaia di piccole diversità ed incompatibilità, e spesso
assicurare la compilazione su sistemi operativi diversi (come Windows,
MacOSX, GNU/Linux, *BSD, Solaris, etc...).
So che il "Make" di Windows è NMAKE. C'è il manuale su MSDN. Le regole
necessarie si scriveranno a mano, penso... o si lascia la fatica all'IDE.
Altrimenti, si possono usare gli autotools (autoconf, automake e
compagnia bella) sotto all'ambiente Cygwin.


 Ciao,

 O almeno non saprei che altre ipotesi fare.
Penso molto semplicemente che internamente l'IDE usi nmake e magari un
file in cui tiene direttive di compilazione specificate dall'utente.
