Newsgroup: it.comp.lang.c++
Titolo: Dove mettere: using namespace ...

In un progetto contenente più file (ad esempio: un file intestazione
ed uno di implementazione per ogni classe), dove andrebbe inserita la
clausola
using namespace std
se in alcune classi utilizzo la classe string?
E' sufficiente inserirla in un solo file o è necessario inserirla in
ogni file che utilizza string? Posso inserirla solo nel file header di
una classe?
GRAZIE
Daniele.


credo che potresti creare un file file_incluso_da_tutti.h del tipo
#ifndef HFILEINCUSODATUTTIH
#define HFILEINCUSODATUTTIH
    using namespace std
 
    //qui puoi inserire altra roba tipo #define "qualcosa" o const "qualcosa"
    //(roba che possa essere ritenuta utile a qualunque modulo del programma)
#endif
e poi ogni file che ha necessita' della using potrebbe contenere al suo
interno
#include "file_incluso_da_tutti.h"
    Marco Guidi
 

 una classe?
Non mi pare una buona idea metterla nel file header. Cosě facendo perdi
un po' il controllo dei namespace. E' vero che molta gente (io in
particolare) non ne fa ancora un utilizzo esteso ma in quel caso il
namespace dovrebbe diventare uno strumento da avere sempre sottomano e
non da mettere nel "dimenticatoio". Sbaglio?
EMG

Approfitto della mail di Daniele Pallastrelli per chiedervi una cosa che mi
assilla da tempo....
cosa è sto namespace???
altra cosa:
le direttive al preprocessore #if eccc........sono da tutte le parti sotto
win32 (e non solo), ma cosa hanno di così importante?

 Daniele.
-- 
Nearly all men can stand adversity, but if you want to test a man's
character, give him power.
		-- Abraham Lincoln

 una classe?
La cosa migliore e' non usare la direttiva `using namespace std',
e in particolare non va usate negli header file, altrimenti tutti
i file che usano (anche indirettamente) quegli header si trovano
il namespace globale sporcato.
Se una classe (o una funzione) fa grande uso di stringhe (o della
libreria standard) puoi mettere una `using std::string' (o `using
namespace std`) nel file di implementazione della classe (o nella
funzione).  In questo gli effetti della using sono locali al file
(o alla funzione) e non si hanno effetti collaterali nel resto del
programma.
	Mauro

 #include "file_incluso_da_tutti.h"
E quali sarebbero i vantaggi di usare `include "file_incluso_da_tutti.h"'
invece di `using namespace std'?
Gli svantaggi sono:
- meno leggibile: tutti sanno cosa fa una direttiva using, ma il 
significato di una #include "nome-generico.h" e' meno ovvia, e 
soprattutto non ci si aspetta che sporchi il namespace globale
con centinaia di nomi che avevano gia' un loro namespace.
- ogni volta che si aggiunge/cambia qualcosa nel file .h tutti
gli altri file devono essere ricompilati, anche se usano solo
la libreria standard (e non la roba del file .h).
- tutti i programmi che intendono aprire il namespace std si
ritrovano automaticamente delle definizioni (o addirittura
delle #define) non richieste (e viceversa: per avere una 
definizione di qualcosa ci si ritrova automaticamente il
namespace std aperto).
	Mauro

 win32 (e non solo), ma cosa hanno di così importante?
Niente. Permettono, in teoria, di ottenere codice più snello in quanto
escludono condizionalmente dalla compilazione le parti indesiderate. In
pratica pare proprio che non funzionino, specie se riferite ai prodotti
Microsoft, appunto così pieni di direttive #ifdef eppure così
elefantiaci... :-)
EMG

 namespace std aperto).
  Pero' se il file .h fosse incluso da tutti *e soli* i file che
  necessitano del namespace std il problema non si porrebbe, credo;
  cioe' credo che i .o derivanti dai .cc che necessitano del
  namespace conterrebbero la (traduzione della ?) using mentre
  gli altri .o no (o sbaglio qualcosa ?).
 Approfitterei di quest'ultima osservazione per porti una
  domanda in generale (vale probabilmente molto piu' in C che in C++):
  ma quando si #include qualche .h necessario per la libreria
  standard non si "vede" forse un sacco di roba inutile ?
  Voglio dire, in genere un modulo esporta qualcosa. Se poi l'utente
  del modulo non ha bisogno di tutto ma solo di una parte che ci si
  puo' fare ?
Grazie,
Marco Guidi
 

    piuttosto che un'arte... :-).
Non è verò. Scritta una funzione ne puoi misurare diversi parametri:
numero di bytes occupati staticamente, numero di bytes occupati in
run-time per i dati, tempo di esecuzione, etc. E da tutti questi puoi
ricavare un indice di efficienza della funzione stessa.
EMG

using namespace std
Non andrebbe inserita da nessuna parte. Stai dicendo al compilatore
di buttare nel namespace globale tutto quello che trova nel namespace
std, ed allora tanto valeva non mettere tutte le classi della libreria
standard in un apposito namespace.
- Anteponi il nome del namespace quando usi le classi : std::
- Usa : using std::nomeClasse
Per i namespaces troppo lunghi puoi usare degli alias :
namespace nomeBreve = NomeMoltoMoltoLungo;
-- 
Roberto Gerola
Email: 
robert...@penguinpowered.com
WWW: 
http://www.penguinpowered.com/~The_Cpp_Compass

   standard non si "vede" forse un sacco di roba inutile ?
Si, ma il caso della libreria standard e' diverso, ed e' diverso
anche il modo in cui si progetta una libreria standard di un
linguaggio rispetto a una libreria normale.
La libreria standard non cambia, non vengono aggiunte nuove 
classi/funzioni durante lo sviluppo di un programma, quindi
non c'e' il rischio di compilazioni extra per dipendenze inutili.
La libreria standard e' standard ed esiste su tutti i compilatori,
S.O., ..., ed e' uguale dappertutto (non e' ancora cosi' ma
ci si sta avvicinando velocemente).
Se un programma dipende da una libreria "normale" solo per un
particolare, e' costretto a portarsi dietro (e a dipendere da)
un sacco di roba inutile, e se la libreria e' disponibile solo
per un compilatore, oppure dipende da altre librerie non portabili?
Un programma che dipende (anche inutilmente) dalla libreria
standard non ha questi problemi.
	Mauro

 elefantiaci... :-)
Negli header file servono anche per evitare inclusioni multiple.
Quando un header viene incluso da altri header, potrebbe
capitare che alla fine venga incluso piu' di una volta.
Il risultato sarebbe una valanga di errori (definizioni duplicate,
identificatori gia' usati, ...).
Per evitare questo si racchiude il contenuto dell'header in
una direttiva condizionale:
  // pippo.h
  #ifndef INCLUDED_PIPPO
  #define INCLUDED_PIPPO
  ....
  #endif
La prima volta INCLUDED_PIPPO non e' definito, quindi viene
visto tutto il contenuto dell'header (compresa la #define), le
volte successive INCLUDED_PIPPO e' gia definito, quindi non
succede niente.
	Mauro

 EMG
Ho riletto il mio post precedente e visto che mi sembra pieno di
cretinate immani forse e' meglio invitare chi lo ha letto a cancellarlo
Marco Guidi
 

 
Si, questo e' vero (anche se non conosco metodi 'standard' per valutare 
il tempo di esecuzione. Io utilizzo le routine rese disponibili da  
VxWorks che e' un S.O. orientato al real-time),
pero' io mi riferivo ad aspetti quali la leggibilita',
la "pulizia del codice" (strano concetto con il quale molti mi fanno   
una 'testa tanto' ma che io non riesco a concepire come piu' importante
rispetto ad altri) la manutenibilita' (che secondo me e' il
piu' importante in generale anche se con qualche eccezione tipo
sistemi real-time,  ma del quale sembra non fregargliene niente a
nessuno in confronto a tutti gli altri), ecc.
In genere quanto sento parlare di software-engeenering sento parlare
piu' di queste cose che non ad esempio di efficienza del codice. 
Cioe', voglio dire che non conosco metodi che siano in grado di fornire
quantitativamente il "livello di leggibilita'" di un programma o il
suo "livello di pulizia del codice", ecc.
In quanto all'efficienza, ti garantisco che non so cosa darei per avere
sottomano dei metodi "standard" per minimizzare il tempo di esecuzione
di funzioni, visto che da un mese sto impazzendo proprio per cercare
di ottimizzare il tempo di esecuzione di
una applicazione real-time che devo riuscire a far girare
con una deadline inferiore ai 10ms. Per ora siamo sui 9.7 ms ma
visto che ancora una certa quantita' di codice piuttosto "pesante" in
termini di tempo di calcolo deve essere inserita => non riusciremo a
stare nei 10ms a meno di non riuscire a ottimizzare in qualche modo
il tutto (cioe' gli 8-9 task in escuzione).


volevo solo aggiungere che nei file heade
(in quelli forniti ad esempio con il compilatore) si possono trovare
spesso anche cose del tipo seguente (e che mi sembrano non eliminabili
in alcuni casi. Se qualcuno sa come si potrebbe raggiungere lo scopo
in altro modo, potrebbe postarlo).
in un qualche .h ad esmpio f1.h
#define ALPHA 1
e poi in qualche altro file (.h o .c o .cc) che include f1.h
(non so se la sintassi e' corretta, ma lo scopo di tali direttive mi sembra
abbastanza ovvio)
#if defined ALPHA
    ....
#else if defined SPARC
   ....
#else  if ...
   ....
#endif
Marco Guidi

 cretinate immani forse e' meglio invitare chi lo ha letto a cancellarlo
Non esagerare. Le tue affermazioni erano invece un ottimo spunto di
riflessione. Non esistono verità assolute.
EMG

 di funzioni,
Vorresti forse un sistema automatico che risolva tutti i tuoi problemi?
Allora poi tu non avresti più lavoro... :-)
EMG