C++ - namespace-alias und vorwärts-Deklaration

Ich bin mit einem C++ Drittanbieter-Bibliothek, die Orte, die alle Ihre Klassen in einem versionierten namespace, nennen wir es tplib_v44. Außerdem definieren Sie eine generische namespace-alias:

namespace tplib = tplib_v44;

Wenn eine vorwärts-deklarieren, die ein Mitglied der Bibliothek in meiner eigenen .h-file, mithilfe der generischen namespace...

namespace tplib { class SomeClassInTpLib; }

... Bekomme ich compiler Fehler auf dem Kopf-in die third-party Bibliothek (die wird später in meine .cpp-Implementierung-Datei):

error C2386: 'tplib' : a symbol with this name already exists in the current scope

Nutzen, wenn ich die version-spezifischen namespace, dann funktioniert alles wunderbar, doch dann ... was ist der Punkt? Was ist der beste Weg, um damit umzugehen?

[BEARBEITEN] zur info für zukünftige Zuschauer, das war der ICU-Bibliothek. Eine Lösung (zumindest in meiner situation) ist in den Kommentaren zu den akzeptierten Antworten.

InformationsquelleAutor Dave Mateer | 2010-06-12
  1. 4

    Sieht es aus wie ein hässlicher workaround, aber keine gute Lösung.

    Für ACE (mit einer anständigen Erklärung) und Xerces (mit einer snarky "dies ist, wie c++ funktioniert" Kommentar) Sie Makros definieren, die Sie verwenden können, um dies zu tun "generisch".

    ACE_BEGIN_VERSIONED_NAMESPACE_DECL
class ACE_Reactor;
ACE_END_VERSIONED_NAMESPACE_DECL

XERCES_CPP_NAMESPACE_BEGIN
class DOMDocument;
class DOMElement;
XERCES_CPP_NAMESPACE_END

    Sieht es aus wie ein unglücklicher c++ Artefakt, versuchen Sie die Suche in Ihrem tplib für diese Makros.

    Standard behandelt namespaces und namespace-Aliase, wie verschiedene Dinge. Du bist deklarieren tplib als ein namespace, so dass, wenn der compiler versucht, einen alias zuweisen später, es kann nicht beides sein, also der compiler meckert.

    • Dieser war sehr nah an, was schließlich für mich arbeiten. Es stellte sich heraus, meine Bibliothek (die ICU-Bibliothek) hat einen kleinen header (uversion.h) das--unter anderem--definiert den namespace-alias. Wenn ich diesen header in meinem Kopf, die ich dann verwenden können, eine Versionsangabe-namespace makro definieren Sie (U_ICU_NAMESPACE) in meiner header-Datei, und Weg mit dem generic-namespace in meiner cpp-Dateien. So, ich bin isoliert von änderungen an versionierten namespace noch mit minimalen compile-time Abhängigkeiten.
    InformationsquelleAutor Stephen
  2. 2

    Ich glaube, dein problem ist durch tplib ein alias, anstatt eine wirkliche namespace

    Da die Versionierung in einem Drittanbieter-Bibliothek, die Sie möglicherweise nicht in der Lage, es zu benutzen, aber mit der Version Namensraum innerhalb einer nicht versionierten namespace (eher als aliasing es) scheint zu funktionieren für g++ 4.0.1 und 4.1.2 . Ich habe jedoch das Gefühl, dass dies nicht funktionieren soll ... und vielleicht gibt es einige andere Probleme, die ich bewusst bin.

    //This is the versioned namespace
namespace tplib_v44
{
   int foo(){ return 1; }
}

//An unversioned namespace using the versioned one
namespace tplib
{
  using namespace tplib_v44;
}


//Since unversioned is a real namespace, not an alias you can add to it normallly.
namespace tplib
{
   class Something {};
}


int main()
{
  //Just to make sure it all works as expected
  tplib::foo();
}
    • Nur Hüte dich, dass dies nicht ein Fehler ausgelöst, wenn Something wurde schon erklärt in der Version Namensraum. Es wird stillschweigend akzeptieren und tplib::Something beziehen sich auf die versionierten, ignorieren tplib::Something. Auch ADL nicht für Anrufe mit Something als argument - die versionierte namespace wird nicht nachgeschlagen werden für die Kandidaten.
    • Das klingt vernünftig. Können Sie ein Beispiel geben, wie ADL scheitern wird in der Fall und nicht den direkten namespace Fall?
    InformationsquelleAutor Michael Anderson
  3. 0

    Äh..., Was Sie sagen, erscheint nach hinten zu mir. Ganz im Gegenteil, was ist der Punkt, der versucht zu erklären, Ihre Klasse als ein Mitglied der tplib namespace? (Vergessen für eine Sekunde, dass es nicht noch einen namespace, sondern ein namespace-alias, das ist der Grund, warum Sie den Fehler.)

    Es ist offensichtlich, dass Sie irgendeine Art von version-control-system baute auf die namespaces und namespace-Aliasen. Wenn Ihre Klasse wird vorgestellt in einer bestimmten "version", der den namespace (wie 44) - das ist der Namensraum muss deklariert werden. Warum sind Sie versuchen zu schieben Ihre Klasse Erklärung "back in time", d.h. in alle früheren Versionen der namespace (wie 43 und, sagen wir, 30)? Ihre Klasse nicht vorhanden in den vorherigen Versionen, so dass Sie nicht sollen, um ihn zu zwingen es.

    • Ich denke, meine ursprüngliche Frage war nicht klar. Die namespace-alias wird von den third-party-Entwickler, so dass ich kann beziehen sich auf Ihre Klassen als tplib::SomeClass. Sie sind mit der Version Namensraum intern. So in Ihre nächste Veröffentlichung, die internen namespace könnte tplib_v50. Aber das werde ich nicht müssen gehen durch alle meine Dateien, und ändern Sie tplib_v44:: zu tplib_v50:: da bin ich mit dem alias. Ich bin nicht deklarieren, meine Klasse in dem namespace; nur vorwärts-Deklaration einer Klasse aus dieser Bibliothek in die header-Datei von meinem Klassen. Hoffe das macht Sinn.
    InformationsquelleAutor AnT
  4. 0

    EDIT: ich habe es darauf hingewiesen, dass ich vergessen habe den Punkt in Frage, bitte fühlen Sie sich frei, zu ignorieren!

    Neben den Problemen, die wurden in den anderen Antworten, auch mich beunruhigt ein bisschen, dass Sie versuchen, fügen Sie Ihren eigenen code von einem Drittanbieter-definierten namespace in den ersten Platz.

    Namespaces existieren, um zu verhindern, dass widersprüchliche Symbole (Klassen, typdefs, enums, etc.) aufeinander, indem Sie in Ihrem eigenen namespace, also die Entwicklung einer einzigartigen voll-qualifizierten symbol von potenziell identisch teilweise qualifizierte diejenigen. Indem Sie Ihre eigenen code zu Dritten namespace kann zu Problemen führen, wenn (zum Beispiel) in einer späteren version Sie sich entscheiden, Sie zu verwenden möchten, das gleiche symbol (wie das hinzufügen Ihrer eigenen SomeClassInTpLib) - alle von einer plötzlichen, die Benennung von Konflikten namespaces sind dazu gedacht zu verhindern, wird hinten Ihre hässlichen Kopf. Deshalb ist es in der Regel schlechte Praxis, um zu den std namespace.

    Eine viel sicherere Lösung, die vermeidet, dass das Problem ganz einfach in Ihrem eigenen Namensraum. Rufen Sie tplib_ex oder etwas ähnliches, und der Verein wird noch klar werden, aber der Konflikt wird nicht ein Problem sein, und Ihre alias-Problem wird auch verschwinden.

    • Er ist nicht, neue Symbole in die Bibliothek, er versucht vorwärts zu deklarieren, die Objekte, die bereits existieren innerhalb der 3rd-party-namespace (Kürzel).
    • Ah, in der Tat. Irgendwie verpasst, dass. Danke für die Korrektur.
    InformationsquelleAutor Mac
  5. 0

    was ist der Punkt?

    Verhindern, dass Sie zusätzliche Sachen in den namespace, vielleicht weil Sie denken, dass Sie zu viel hinzufügen, weitere Namen, bald (und die Tatsache, dass Sie mit einem versionierten namespace könnte darauf hindeuten, dass). Aber diese sind nur Spekulationen. Dies hat den positiven Effekt der Verhütung forward-Deklarationen in den namespace, die Sie denken, ist mehr angemessen, so dass ich denke, es ist einfach schlechter Programmierstil auf Ihrer Seite.

    Was ist der beste Weg, um damit umzugehen?

    Es ist nicht der beste Weg, aber versuchen zu vermeiden, mit Makros, Makros sind hässlich und nicht schön zu sehen (ich weiß nicht wie alle, dass groß-Zeug). Wenn Ihre Sorge darüber, "was passiert, wenn Sie version ändern?" (ja, in der Theorie, die Sie ändern müssen "v44" zu "v45" in allen Ihren code)

    dann nur mit 1 einzigen header zu forward-deklarieren Sie alles, was Sie brauchen.

    TpLibForwards.hpp

    #ifdef XXXXXX_TPLIB
   #error "XXXXXX_TPLIB is already taken, change to something else"
#endif
#define XXXXXX_TPLIB  tplib_v44 
//... and that's why I don't like keeping macros around..

namespace XXXXXX_TPLIB
{

    //FORWARD DECLARATIONS
    class A1;
    class A2;
    //...
}
namespace tplib = XXXXXX_TPLIB;
#undef XXXXXX_TPLIB

    Wenn Sie ändern die Bibliothek dann müssen Sie nur anwenden 1 ändern und in 1 Datei. Viele Programmierer schon halten forward-Deklaration in einem Punkt, denn das ist viel mehr überschaubar, und im Falle Sie haben, um vorwärts zu erklären, viele Dinge, die Sie halten andere Header-Reiniger und vieles mehr lesbar.

    #include <TpLibForwards.hpp> //my forwards declarations
    InformationsquelleAutor GameDeveloper
Schreibe einen Kommentar