Praktisch sicher anzunehmen sizeof (std :: unordered_map <std :: string, T>) ist für alle T gleich?

Question

Ich bin in einer Situation, wo ich eine zirkuläre Abhängigkeitsschleife zwischen den Definitionen von zwei Klassen habe, wo (so weit ich sagen kann) beide Klassen den anderen Typ benötigen, um ein vollständiger Typ zu sein, um sie richtig zu definieren.

Vereinfacht ausgedrückt, was ich vereinfachte Version müssen, was los ist:

struct Map; 

struct Node { 
    // some interface... 
private: 
    // this cannot be done because Map is an incomplete type 
    char buffer[sizeof(Map)]; 
    // plus other stuff... 
    void* dummy; 
}; 

struct Map { 
    // some interface... 
private: 
    // this is Map's only member 
    std::unordered_map<std::string, Node> map_; 
}; 

Die Situation ist tatsächlich komplizierter als die oben, da Node tatsächlich wird eine Variante Typ (ähnlich boost::variant sein) das verwendet Placement neu, um explizit einen von mehreren Arten von Objekten in einem vorher zugeordneten (und mit richtiger Ausrichtung, die ich in dieser Vereinfachung ignoriere) Puffer zu konstruieren: der Puffer ist daher nicht genau sizeof(Map), sondern eher eine bestimmte Konstante, die abhängig ist sizeof(Map). Das Problem besteht offensichtlich darin, dass sizeof(Map) nicht verfügbar ist, wenn Map nur vorwärts deklariert ist. Außerdem, wenn ich die Reihenfolge der Deklarationen zu Forward deklarieren Node zuerst, dann Kompilierung von Map schlägt fehl, wie std::unordered_map<std::string, Node> kann nicht instanziiert werden, wenn Node ist ein unvollständiger Typ, zumindest mit meinem GCC 4.8.2 auf Ubuntu. (Ich weiß, es hängt von dem libstdC++ Version mehr als die GCC-Version, aber ich weiß nicht so leicht, wie das finden ...)

Als Alternative Ich betrachte die folgende Abhilfe:

struct Node { 
    // some interface... 
private: 
    // doing this instead of depending on sizeof(Map) 
    char buffer[sizeof(std::unordered_map<std::string, void*>)]; 
    // other stuff... 
    void* dummy; 
}; 

struct Map { 
    // some interface... 
private: 
    // this is Map's only member 
    std::unordered_map<std::string, Node> map_; 
}; 

// and asserting this after the fact to make sure buffer is large enough 
static_assert (sizeof(Map) <= sizeof(std::unordered_map<std::string, void*>), 
    "Map is unexpectedly too large"); 

Dies beruht im Wesentlichen auf der Annahme, dass std::unordered_map<std::string, T> die gleiche Größe für alle T ist, die aus meinen Tests mit GCC wahr scheint. also dreifache

ist Meine Frage:

• Gibt es etwas in der C++ Standard, der erfordert, dass diese Annahme wahr zu halten? (Ich gehe davon aus, nein, aber wenn es ist, würde ich angenehm überrascht sein ...)

• Wenn nicht, ist es praktisch sicher davon ausgehen, es für alle vernünftigen Implementierungen gilt sowieso, und dass die statische Behauptung in meiner überarbeiteten Version wird nie feuern?

• Schließlich gibt es eine bessere Problemumgehung für dieses Problem, an das ich nicht gedacht habe? Ich bin sicher, es ist möglich, es ist etwas offensichtlich, dass ich stattdessen tun kann, dass ich nicht gedacht haben, aber leider kann ich mich nichts ...

Answer 1

Gehen Sie einfach vor und nehmen Sie an. Dann static_assert bei der Konstruktion, dass Sie Recht haben.

Es gibt raffiniertere Lösungen, wie herauszufinden, wie boost rekursive Datenstrukturen arbeiten und die Technik hier anwenden (was möglicherweise das Schreiben einer eigenen Karte erforderlich macht), oder einfach einen boost:: Container verwenden, der unvollständige Datenstrukturen unterstützt.

Answer 2

1) Keine

2) I bin nicht sicher

3) Sie können auch Entwurfsmuster Factory-Methode verwenden. Ihre Fabrik wird Objekt basierend auf Map Variante zurückgeben (BEARBEITEN: Ich meine, Sie werden Map variant instance als Parameter verwenden und die Factory-Methodenimplementierung wird diese Information verwenden, um ein Rückgabeobjekt entsprechend zu erzeugen) und kann Puffer zur Größenzuordnung vorbelegen.

Answer 3

1) Keine

2) STL Behälter nicht mit einem unvollständigen Typ instanziiert werden.Offensichtlich erlauben einige Compiler dies jedoch. Dies nicht zuzulassen, war keine triviale Entscheidung und in vielen Fällen wird Ihre Annahme wahr sein. This Artikel könnte Sie interessieren. Angesichts der Tatsache, dass dieses Problem gemäß dem Standard nicht lösbar ist, ohne eine indirekte Ebene hinzuzufügen, und das wollen Sie nicht tun. Ich muss dir nur einen Hinweis geben, dass du in der Tat keine Dinge nach dem Standard machst.

Having said that, ich denke, dass Ihre Lösung die beste ist mit STL-Containern. Und die statische Behauptung wird tatsächlich warnen, wenn die Größe tatsächlich die erwartete Größe überschreitet.

3) Ja mit einer weiteren Schicht Indirektionsebene Zugabe wäre meine Lösung die folgende sein:

Das Problem, das Sie ist haben, dass die Größe eines Objekts auf der Größe seiner Arrays abhängt. Sagen Sie bitte ein Objekt A und Objekt und B haben:

struct A 
{ 
    char sizeof[B] 
} 

struct B 
{ 
    char sizeof[A] 
} 

Objekt A wird wachsen, um Haus Zeichen für die Größe von B. Aber dann wiederum Objekt B wird wachsen müssen. Ich denke, du kannst sehen, wohin das geht. Ich weiß, das ist dein genaues Problem, aber ich denke, die zugrunde liegenden Prinzipien sind ziemlich ähnlich.

In diesem speziellen Fall würde ich es lösen, indem die nur ein Zeiger auf seine

char buffer[sizeof(Map)]; 

Linie zu ändern:

char* buffer 

und dynamisch zuweisen Speicher nach der Initialisierung. Säen Sie Ihre CPP-Datei wie folgt aussehen würde:

//node.cpp 
//untested code 
node::node() 
{ 
    buffer = malloc(sizeof(map)); 
} 

node::~node() 
{ 
    free buffer; 
} 

Answer 4

1) Wahrscheinlich nicht

2) Da es aussieht wie es auf die Umsetzung völlig abhängig ist, das ist ein großes Risiko, da dies buchstäblich in jedem Compiler Update brechen .

3) Sie können boost::unordered_map verwenden, die unvollständige Typen akzeptieren und damit Ihr Problem lösen wird.