Praticamente sicuro di assumere sizeof (std :: unordered_map <std :: string, T>) è lo stesso per tutti i T?

Question

Sono in una situazione in cui ho un ciclo di dipendenza circolare tra le definizioni di due classi, dove (per quanto posso dire) entrambe le classi hanno bisogno che l'altro tipo sia un tipo completo per definirle correttamente.

In termini semplificati, quello che mi serve versione semplificata di ciò che accade:

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_; 
}; 

La situazione è in realtà più complicata di quanto sopra, poiché Node è in realtà sarà di tipo variante (simile a boost::variant) che utilizza il posizionamento nuovo per costruire esplicitamente uno di più tipi di oggetti in un buffer preallocato (e con allineamento corretto, che sto ignorando in questa semplificazione): il buffer non è quindi esattamente sizeof(Map) ma piuttosto una costante calcolata che dipende da sizeof(Map).

Il problema, ovviamente, è che sizeof(Map) non è disponibile quando Map viene inoltrato solo in avanti. Inoltre, se cambio l'ordine delle dichiarazioni da inoltrare prima dichiarare Node, la compilazione di Map non riesce, poiché std::unordered_map<std::string, Node> non può essere istanziato quando Node è un tipo incompleto, almeno con il mio GCC 4.8.2 su Ubuntu. (Lo so che dipende dalla libstdC++ versione più rispetto alla versione GCC, ma non so come trovare facilmente quello ...)

In alternativa, sto considerando la seguente soluzione:

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"); 

Questo fondamentalmente si basa sul presupposto che std::unordered_map<std::string, T> abbia la stessa dimensione per tutti i T, il che sembra essere valido per i miei test con GCC.

La mia domanda è dunque triplice:

• C'è qualcosa nello standard C++ che richiede che questa ipotesi di tenere vero? (Sto assumendo di no, ma se c'è sarei piacevolmente sorpreso ...)

• In caso contrario, è praticamente lecito ritenere che vale per tutte le implementazioni ragionevoli in ogni caso, e che l'affermazione statica nella mia versione rivista non sparerà mai?

• Infine, c'è una soluzione migliore a questo problema a cui non ho pensato? Sono sicuro che è possibile che ci sia qualcosa di ovvio che posso fare, invece, che non ho pensato, ma purtroppo non posso pensare a niente ...

Answer 1

Basta andare avanti e assumere. Quindi al static_assert alla costruzione hai ragione.

ci sono soluzioni più elaborate, come per capire come aumentare le strutture di dati ricorsive lavoro e applicando la tecnica qui (che potrebbe richiedere per iscritto la propria mappa), o semplicemente utilizzando un contenitore boost:: che supporta strutture di dati incompleti.

Answer 2

1) No

2) I Non sono sicuro

3) È inoltre possibile utilizzare il modello di progettazione Metodo di produzione. La tua fabbrica restituirà l'oggetto in base alla variante Map (MODIFICA: voglio dire che utilizzerai l'istanza Variante della mappa come parametro e l'implementazione del metodo Factory utilizzerà tali informazioni per creare di conseguenza l'oggetto di ritorno) e può preallocare il buffer per correggere la dimensione.

Answer 3

1) Nessun

2) contenitori STL non può essere istanziata con un tipo incompleto.Tuttavia, a quanto pare alcuni compilatori lo consentono. Non permettere ciò non è stata una decisione banale e in molti casi la tua ipotesi sarà vera. L'articolo This potrebbe interessarti. Dato il fatto che secondo lo standard questo problema non è risolvibile senza aggiungere uno strato di riferimento indiretto e non si vuole farlo. Devo solo dare un testa a testa che in realtà non stai facendo le cose secondo lo standard.

Detto questo, penso che la soluzione sia la migliore con i contenitori STL. E l'asserzione statica avvertirà effettivamente quando la dimensione supera effettivamente la dimensione prevista.

3) Sì, con l'aggiunta di un ulteriore livello di indirezione, la mia soluzione sarebbe il seguente:

Il problema che hai è che la dimensione di un oggetto, dipende dalle dimensioni dei suoi array. Diciamo che avere un oggetto A e B e l'oggetto:

struct A 
{ 
    char sizeof[B] 
} 

struct B 
{ 
    char sizeof[A] 
} 

oggetto A crescerà, al fine di caratteri casa per le dimensioni di B. Ma poi a sua volta l'oggetto B dovrà crescere. Immagino che tu possa vedere dove sta andando. So che questo è il tuo problema esatto, ma penso che i principi di base siano abbastanza simili.

In questo caso particolare voglio risolverlo cambiando la linea

char buffer[sizeof(Map)]; 

essere solo un puntatore:

char* buffer 

E dinamicamente allocare memoria dopo l'inizializzazione. Semina il file cpp sarebbe simile a questa:

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

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

Answer 4

1) Probabilmente non

2) Dal momento che sembra che sia totalmente dipendente implementazione, che è un grande rischio come questo può letteralmente rompere in qualsiasi aggiornamento compilatore .

3) È possibile utilizzare boost::unordered_map che accetta tipi incompleti e quindi risolverà il problema.