2013-06-24 10 views
6

Sono un nuovo arrivato C++, cercando di imparare la lingua in parallelo mentre lavoro su un progetto che lo richiede. Sto usando una libreria open source abbastanza popolare e stabile per fare un sacco di lavori pesanti. Leggendo la fonte, le esercitazioni e gli esempi di codice per la libreria, ho notato che usano sempre nomi completi quando dichiarano i tipi, il che spesso si traduce in molto righe lunghe e prolisse con un sacco di :: s. Questa è considerata la migliore pratica in C++? C'è un modo diverso per affrontare questo?Utilizzo di nomi completi in C++

+0

[Google namespace per C++] (http://stackoverflow.com/questions/6955023/c -namespace-best-practice-dilemma) "using std :: string" o "using namespace std" – Huy

+0

Senza vedere il codice in questione, è impossibile rispondere. Ma una lunga serie di nomi spazio dei nomi '::' separati di fronte a un nome probabilmente non è corretta. –

+0

..... né sbagliato –

risposta

7

Potrebbero aver trovato più facile rispondere a molte domande di persone che hanno provato il codice di esempio e hanno scoperto che non funzionava, solo perché non "utilizzavano" gli spazi dei nomi coinvolti.

Practices variare - se si sta lavorando su un progetto di grandi dimensioni con un sacco di diverse biblioteche e nomi di scontri, si potrebbe desiderare di utilizzare in modo proattivo più qualificatori namespace costantemente in modo che quando si aggiungono il nuovo codice non dovrete andare a rendere il vecchio codice più esplicito su ciò che sta tentando di utilizzare.

Stilisticamente, alcune persone preferiscono sapere esattamente ciò che viene indicato a potenzialmente dover scavare intorno o seguire un IDE "andare a dichiarazioni" caratteristica (se disponibili), mentre altre persone come la concisione e di vedere più piena qualificazione namespace solo sul riferimenti "eccezionali" a spazi dei nomi che non sono stati inclusi - una prospettiva più contestuale.

È anche normale evitare di "usare il namespace xxx;" in un file di intestazione, poiché il codice client che include quell'intestazione non sarà in grado di disattivarlo e il contenuto di tale spazio dei nomi verrà permanentemente scaricato nel loro "spazio di ricerca" predefinito. Quindi, se stai guardando il codice in un'intestazione, c'è una ragione per cui potrebbero essere più espliciti. A differenza di ciò, è possibile "usare lo spazio dei nomi" all'interno di un ambito come un corpo di una funzione, anche in un'intestazione, e questo non influenzerà l'altro codice. È più normale utilizzare uno spazio dei nomi all'interno di un file di implementazione che ci si aspetta sia il file finale in un'unità di traduzione, compilando una libreria o un oggetto che si collegherà all'eseguibile finale, o forse un'unità di traduzione che crea esso stesso l'eseguibile.

5

Prime typedef:

typedef std::vector<MyTypeWithLongName>::const_iterator MyTypeIt; 
//use MyTypeIt from now on 

In secondo luogo "utilizzando"

using std::string; 
//use string instead of std::string from now on 

Terzo "utilizzando namespace"

using namespace std; 
//Use all things from std-namespace without std:: in front (string, vector, sort etc.) 

Per la migliore pratica: non utilizzare 'usando' e 'using namespace' molto. Quando devi usarlo (a volte mantiene pulito il codice) non inserirlo mai nell'intestazione ma nel file .cpp. Tendo ad usare uno di quelli sopra se i nomi diventano veramente lunghi o devo usare molto i tipi nello stesso file.

+0

preferisci davvero i typedef all'utilizzo? – aaronman

+0

Solo per tipi di stl. Questi tendono ad essere piuttosto lunghi come mostrato nel primo esempio. Volevo solo contare le possibilità, non classificarle – Marius

+2

. 'MyTypeIt' è migliore di' const_iterator'. –

2

Se si scrivono le proprie librerie, si avrà sicuramente un uso massiccio degli spazi dei nomi, nella propria applicazione di base dovrebbero esserci meno utilizzi. Per quanto riguarda il fare qualcosa di simile std::string invece di partire con using namespace std; imo la prima versione è migliore perché è più descrittiva e meno soggetto a errori