Existe-t-il des garanties de mise en page standard pour les conteneurs STL?

struct A { 
    // ... some methods ... 
    std::vector<int> foo; 
    // ... more data members ... 
};

Avec g ++ 4,7 et libstdC++, j'obtiens std::is_standard_layout<A>::value == true.
Mais que se passe-t-il avec d'autres compilateurs ou bibliothèques standard?
Y a-t-il des garanties que (au moins certains?) Les conteneurs STL ne rompent pas la disposition standard?Existe-t-il des garanties de mise en page standard pour les conteneurs STL?

Contexte:

struct B : A { // still standard-layout 
    // ... more methods (but no new variables!) 
    void bar(); 
};

Cela permet l'utilisation de static_cast<B &>(a).bar() même pour A a;. (Je ne dis pas que c'est un bon design!).

Source

2013-03-03 smilingthax

L'effet de 'static_cast (a) .bar()' est indéfini. Il peut très bien «fonctionner» dans le sens où il semble faire ce que vous pensez qu'il pourrait faire, mais il n'est en aucun cas permis par la définition du langage. –

@PeteBecker La mise en page standard garantit que l'adresse de la classe de base A est la même que l'adresse de B. Par conséquent, static_cast (& a) -> bar() doit au moins fonctionner. Je ne suis pas tout à fait sûr d'utiliser des références, bien que – smilingthax

Um, non, cela ne signifie pas que vous pouvez prétendre qu'un objet d'un type de base est un objet d'un type dérivé. Encore une fois, le comportement est indéfini. –

Non, il n'y a aucune garantie.

Le 11 C++ standard mentionne explicitement quand une classe doit ont mise en page standard (par exemple la classe mutex, la classe atomic_flag, etc.).

Le mot «mise en page» n'apparaît pas dans l'ensemble de l'article 23 (Bibliothèque de conteneurs). Je crois que cela suffit pour supposer qu'aucune garantie n'est donnée.

Source

2013-03-03 16:30:01

Existe-t-il des garanties de mise en page standard pour les conteneurs STL?

Répondre

Questions connexes