Esiste un modo migliore per esprimere gli spazi dei nomi nidificati in C ++ all'interno dell'intestazione

Sono passato da C ++ a Java e C # e penso che l'uso di spazi dei nomi / pacchetti sia molto migliore lì (ben strutturato). Poi sono tornato a C ++ e ho provato a usare gli spazi dei nomi allo stesso modo, ma la sintassi richiesta è orribile all'interno del file di intestazione.

namespace MyCompany
{
    namespace MyModule
    {
        namespace MyModulePart //e.g. Input
        {
            namespace MySubModulePart
            {
                namespace ...
                {
                    public class MyClass    

Anche quanto segue mi sembra strano (per evitare il rientro profondo):

namespace MyCompany
{
namespace MyModule
{
namespace MyModulePart //e.g. Input
{
namespace MySubModulePart
{
namespace ...
{
     public class MyClass
     {

C'è un modo più breve per esprimere quanto sopra? Mi manca qualcosa di simile

namespace MyCompany::MyModule::MyModulePart::...
{
   public class MyClass

Aggiornare

Ok, alcuni dicono che il concetto di utilizzo in Java / C # e C ++ è diverso. Veramente? Penso che il caricamento delle classi (dinamico) non sia l'unico scopo per i namespace (questa è una prospettiva ragionata molto tecnica). Perché non dovrei usarlo per una leggibilità e strutturazione, ad esempio pensare a "IntelliSense".

Attualmente, non esiste alcuna logica / colla tra uno spazio dei nomi e ciò che puoi trovare lì. Java e C # lo fanno molto meglio ... Perché includere <iostream>e avere lo spazio dei nomi std? Ok, se dici che la logica dovrebbe fare affidamento sull'intestazione da includere, perché #include non utilizza una sintassi amichevole "IntelliSense" come #include <std::io::stream>o <std/io/stream>? Penso che la strutturazione mancante nelle librerie predefinite sia una debolezza di C ++ rispetto a Java / C #.

Se l'unicità di conflitti avidi è un punto (che è anche un punto di C # e Java) una buona idea è usare il nome del progetto o il nome dell'azienda come spazio dei nomi, non credi?

Da un lato si dice che il C ++ è il più flessibile ... ma tutti hanno detto "non farlo"? Mi sembra che il C ++ possa fare molte cose ma ha una sintassi orribile anche per le cose più semplici in molti casi rispetto a C #.

Aggiorna 2

La maggior parte degli utenti afferma che non ha senso creare un annidamento più profondo di due livelli. Ok, allora che dire degli spazi dei nomi Windows :: UI :: Xaml e Windows :: UI :: Xaml :: Controls :: Primitives nello sviluppo di Win8? Penso che l'utilizzo degli spazi dei nomi da parte di Microsoft abbia senso ed è effettivamente più profondo di soli 2 livelli. Penso che librerie / progetti più grandi necessitino di un annidamento più profondo (odio i nomi di classi come ExtraLongClassNameBecauseEveryThingIsInTheSameNameSpace ... quindi potresti mettere tutto anche nello spazio dei nomi globale.)

Aggiornamento 3 - Conclusione

La maggior parte dice "non farlo", ma ... anche il boost ha una nidificazione più profonda di uno o due livelli. Sì, è una libreria ma: se vuoi codice riutilizzabile, tratta il tuo codice come una libreria che daresti a qualcun altro. Uso anche una nidificazione più profonda per scopi di scoperta utilizzando spazi dei nomi.

C ++ 17 potrebbe semplificare la definizione dello spazio dei nomi annidato:

namespace A::B::C {
}

è equivalente a

namespace A { namespace B { namespace C {
} } }

Vedere (8) nella pagina dello spazio dei nomi su cppreference:
http://en.cppreference.com/w/cpp/language/namespace

Per evitare un rientro molto profondo, di solito lo faccio in questo modo:

namespace A { namespace B { namespace C
{
    class X
    {
        // ...
    };
}}}

Sostengo pienamente la risposta di Peterchen, ma voglio aggiungere qualcosa che affronti un'altra parte della tua domanda.

La dichiarazione degli spazi dei nomi è uno dei casi molto rari in C ++ in cui effettivamente mi piace l'uso di #defines.

#define MY_COMPANY_BEGIN  namespace MyCompany { // begin of the MyCompany namespace
#define MY_COMPANY_END    }                     // end of the MyCompany namespace
#define MY_LIBRARY_BEGIN  namespace MyLibrary { // begin of the MyLibrary namespace
#define MY_LIBRARY_END    }                     // end of the MyLibrary namespace

Ciò elimina anche la necessità di commenti vicino alla parentesi graffa di chiusura dello spazio dei nomi (Hai mai fatto scorrere verso il basso fino alla fine di un file sorgente di grandi dimensioni e hai provato ad aggiungere / rimuovere / bilanciare le parentesi graffe che mancavano di commenti su quale parentesi graffa chiude quale ambito? .).

MY_COMPANY_BEGIN
MY_LIBRARY_BEGIN

class X { };

class Y { };

MY_LIBRARY_END
MY_COMPANY_END

Se vuoi mettere tutte le dichiarazioni dello spazio dei nomi su una singola riga, puoi farlo anche con un po 'di (piuttosto brutta) magia del preprocessore:

// helper macros for variadic macro overloading
#define VA_HELPER_EXPAND(_X)                    _X  // workaround for Visual Studio
#define VA_COUNT_HELPER(_1, _2, _3, _4, _5, _6, _Count, ...) _Count
#define VA_COUNT(...)                           VA_HELPER_EXPAND(VA_COUNT_HELPER(__VA_ARGS__, 6, 5, 4, 3, 2, 1))
#define VA_SELECT_CAT(_Name, _Count, ...)       VA_HELPER_EXPAND(_Name##_Count(__VA_ARGS__))
#define VA_SELECT_HELPER(_Name, _Count, ...)    VA_SELECT_CAT(_Name, _Count, __VA_ARGS__)
#define VA_SELECT(_Name, ...)                   VA_SELECT_HELPER(_Name, VA_COUNT(__VA_ARGS__), __VA_ARGS__)

// overloads for NAMESPACE_BEGIN
#define NAMESPACE_BEGIN_HELPER1(_Ns1)             namespace _Ns1 {
#define NAMESPACE_BEGIN_HELPER2(_Ns1, _Ns2)       namespace _Ns1 { NAMESPACE_BEGIN_HELPER1(_Ns2)
#define NAMESPACE_BEGIN_HELPER3(_Ns1, _Ns2, _Ns3) namespace _Ns1 { NAMESPACE_BEGIN_HELPER2(_Ns2, _Ns3)

// overloads for NAMESPACE_END
#define NAMESPACE_END_HELPER1(_Ns1)               }
#define NAMESPACE_END_HELPER2(_Ns1, _Ns2)         } NAMESPACE_END_HELPER1(_Ns2)
#define NAMESPACE_END_HELPER3(_Ns1, _Ns2, _Ns3)   } NAMESPACE_END_HELPER2(_Ns2, _Ns3)

// final macros
#define NAMESPACE_BEGIN(_Namespace, ...)    VA_SELECT(NAMESPACE_BEGIN_HELPER, _Namespace, __VA_ARGS__)
#define NAMESPACE_END(_Namespace, ...)      VA_SELECT(NAMESPACE_END_HELPER,   _Namespace, __VA_ARGS__)

Ora puoi farlo:

NAMESPACE_BEGIN(Foo, Bar, Baz)

class X { };

NAMESPACE_END(Baz, Bar, Foo) // order doesn't matter, NAMESPACE_END(a, b, c) would work equally well

Foo::Bar::Baz::X x;

Per annidare più in profondità di tre livelli dovresti aggiungere macro di supporto fino al conteggio desiderato.

Gli spazi dei nomi C ++ vengono utilizzati per raggruppare le interfacce, non per dividere componenti o esprimere divisione politica.

Lo standard fa di tutto per proibire l'uso di spazi dei nomi in stile Java. Ad esempio, gli alias dello spazio dei nomi forniscono un modo per utilizzare facilmente nomi di spazi dei nomi lunghi o profondamente nidificati.

namespace a {
namespace b {
namespace c {}
}
}

namespace nsc = a::b::c;

Ma namespace nsc {}allora sarebbe un errore, perché uno spazio dei nomi può essere definito solo utilizzando il suo nome-spazio dei nomi originale . Essenzialmente lo standard rende le cose facili per l' utente di una simile libreria ma difficili per l' implementatore . Questo scoraggia le persone dallo scrivere cose del genere, ma ne mitiga gli effetti se lo fanno.

Dovresti avere uno spazio dei nomi per interfaccia definito da un insieme di classi e funzioni correlate. Le interfacce secondarie interne o facoltative potrebbero andare in spazi dei nomi annidati. Ma più di due livelli di profondità dovrebbero essere una bandiera rossa molto seria.

Prendi in considerazione l'utilizzo di caratteri di sottolineatura e prefissi identificativi in ​​cui l' ::operatore non è necessario.

No, e per favore non farlo.

Lo scopo degli spazi dei nomi è principalmente risolvere i conflitti nello spazio dei nomi globale.

Uno scopo secondario è l'abbreviazione locale dei simboli; ad esempio, un UpdateUImetodo complesso può utilizzare un using namespace WndUIper utilizzare simboli più brevi.

Sono su un progetto 1.3MLoc e gli unici spazi dei nomi che abbiamo sono:

• librerie COM esterne importate (principalmente per isolare i conflitti di intestazione tra #importe #include windows.h)
• Un livello di spazi dei nomi "API pubbliche" per determinati aspetti (interfaccia utente, accesso al database ecc.)
• Spazi dei nomi "Dettagli implementazione" che non fanno parte dell'API pubblica (spazi dei nomi anonimi in .cpp o ModuleDetailHereBeTygersspazi dei nomi nelle librerie di sola intestazione)
• le enumerazioni sono il problema più grande nella mia esperienza. Inquinano come un matto.
• Sento ancora che sono troppi spazi dei nomi

In questo progetto, i nomi delle classi ecc. Usano un codice "regione" di due o tre lettere (ad es. CDBNodeInvece di DB::CNode). Se preferisci quest'ultimo, c'è spazio per un secondo livello di spazi dei nomi "pubblici", ma non di più.

Le enumerazioni specifiche della classe ecc. Possono essere membri di quelle classi (anche se sono d'accordo che non è sempre buono, ea volte è difficile dire se dovresti)

Raramente è necessario nemmeno uno spazio dei nomi "azienda", tranne se si hanno grossi problemi con le librerie di terze parti che sono distribuite come binarie, non forniscono il proprio spazio dei nomi e non possono essere facilmente inseriti in uno (ad esempio in un file binario distribuzione). Eppure, nella mia esperienza costringere loro in uno spazio dei nomi è molto più facile da fare.

[modifica] Secondo la domanda di follow-up di Stegi:

Ok, allora che dire degli spazi dei nomi Windows :: UI :: Xaml e Windows :: UI :: Xaml :: Controls :: Primitives nello sviluppo di Win8? Penso che l'utilizzo degli spazi dei nomi da parte di Microsoft abbia senso ed è effettivamente più profondo di soli 2 livelli

Scusa se non sono stato abbastanza chiaro: due livelli non sono un limite rigido e altri non sono intrinsecamente negativi. Volevo solo sottolineare che raramente ne occorrono più di due, dalla mia esperienza, anche su una grande base di codice. La nidificazione più profonda o più superficiale è un compromesso.

Ora, il caso Microsoft è probabilmente diverso. Presumibilmente un team molto più grande e tutto il codice è libreria.

Presumo che Microsoft stia imitando qui il successo della libreria .NET, dove gli spazi dei nomi contribuiscono alla rilevabilità della vasta libreria. (.NET ha circa 18000 tipi.)

Suppongo inoltre che ci sia un ottimo (ordine di grandezza di) simboli in uno spazio dei nomi. diciamo, 1 non ha senso, 100 suona bene, 10000 è chiaramente troppo.

TL; DR: È un compromesso e non abbiamo numeri precisi. Gioca sul sicuro, non esagerare in nessuna direzione. Il "Non farlo" deriva semplicemente dal "Hai problemi con quello, io avrei problemi con quello, e non vedo un motivo per cui avresti bisogno.".

Ecco una citazione dai documenti di Lzz (Lazy C ++):

Lzz riconosce i seguenti costrutti C ++:

definizione dello spazio dei nomi

Uno spazio dei nomi senza nome e tutte le dichiarazioni incluse vengono emesse nel file di origine. Questa regola prevale su tutte le altre.

Il nome di uno spazio dei nomi denominato può essere qualificato.

   namespace A::B { typedef int I; }

è equivalente a:

   namespace A { namespace B { typedef int I; } }

Ovviamente la qualità dei sorgenti che dipende da tali strumenti è discutibile ... direi che è più una curiosità, dimostrando che la malattia di sintassi indotta dal C ++ può assumere molte forme (anch'io ho la mia ...)

Entrambi gli standard (C ++ 2003 e C ++ 11) sono molto espliciti sul fatto che il nome dello spazio dei nomi è un identificatore. Ciò significa che sono necessarie intestazioni nidificate esplicite.

La mia impressione che questo non sia un grosso problema per consentire l'inserimento di identificatori qualificati oltre a un semplice nome dello spazio dei nomi, ma per qualche motivo ciò non è consentito.

Puoi usare questa sintassi:

namespace MyCompany {
  namespace MyModule {
    namespace MyModulePart //e.g. Input {
      namespace MySubModulePart {
        namespace ... {
          class MyClass;
        }
      }
    }
  }
}

// Here is where the magic happens
class MyCompany::MyModule::MyModulePart::MySubModulePart::MyYouGetTheIdeaModule::MyClass {
    ...
};

Nota che questa sintassi è valida anche in C ++ 98 ed è quasi simile a ciò che è ora disponibile in C ++ 17 con definizioni di spazio dei nomi annidate .

Buon divertimento!

Fonti:

• http://seanmiddleditch.com/unnest-c-namespaces/
• http://www.nuonsoft.com/blog/2017/08/01/c17-nested-namespaces/

Questo documento copre l'argomento piuttosto bene: Namespace Paper

Il che fondamentalmente si riduce a questo. Più lunghi sono gli spazi dei nomi, maggiori sono le probabilità che le persone utilizzino la using namespacedirettiva.

Quindi guardando il seguente codice puoi vedere un esempio in cui questo ti farà male:

namespace abc { namespace testing {
    class myClass {};
}}

namespace def { namespace testing {
    class defClass { };
}}

using namespace abc;
//using namespace def;

int main(int, char**) {
    testing::myClass classInit{};
}

Questo codice verrà compilato correttamente, tuttavia, se si rimuove il commento dalla riga, //using namespace def;lo spazio dei nomi "testing" diventerà ambiguo e si verificheranno conflitti di denominazione. Ciò significa che la tua base di codice può passare da stabile a instabile includendo una libreria di terze parti.

In C #, anche se dovessi usare using abc;e using def;il compilatore è in grado di riconoscerlo testing::myClasso anche solo myClassè solo nello abc::testingspazio dei nomi, ma C ++ non lo riconoscerà e verrà rilevato come una collisione.

Sì, dovrai farlo così

namespace A{ 
namespace B{
namespace C{} 
} 
}

Tuttavia, stai cercando di utilizzare gli spazi dei nomi in un modo in cui non dovrebbero essere utilizzati. Controlla questa domanda, forse la troverai utile.

[EDIT:]
Poiché gli spazi dei nomi annidati c ++ 17 sono supportati come funzionalità del linguaggio standard ( https://en.wikipedia.org/wiki/C%2B%2B17 ). Al momento, questa funzione non è supportata in g ++ 8, ma può essere trovata nel compilatore in clang ++ 6.0.

[CONCLUSIONE:]
Usa clang++6.0 -std=c++17come comando di compilazione predefinito. Quindi tutto dovrebbe funzionare bene e sarai in grado di compilare connamespace OuterNS::InnerNS1::InnerNS2 { ... } tuoi file.

[RISPOSTA ORIGINALE:]
Poiché questa domanda è un po 'vecchia, presumo che tu sia andato avanti. Ma per altri, che stanno ancora cercando una risposta, ho avuto la seguente idea:

(Potrei fare una pubblicità per Emacs qui :)?) Pubblicare un'immagine è molto più facile e più leggibile che inserire semplicemente codice. Non intendo fornire una risposta completa a tutti i casi d'angolo, volevo semplicemente dare qualche ispirazione. (Sostengo totalmente C # e ritengo che in molti casi C ++ dovrebbe adottare alcune funzionalità OOP, dal momento che C # è popolare principalmente per la sua comparabile facilità d'uso).