disposition de la mémoire des objets en C++

Disposition de la mémoire est le plus souvent laissée à la mise en œuvre. La clé d'exception est que les variables de membre pour un accès rédacteur de devis sera dans l'ordre de leur déclaration.

§ 9.2.14

Non membres de données d'une (non syndiqués) de classe avec le même accès
contrôle (article 11) sont réparties de façon que, plus tard, les membres ont plus de
les adresses à l'intérieur d'un objet de classe. La commande de répartition de la non-statique
les membres de données avec différents contrôle d'accès n'est spécifié (11).
La mise en œuvre de l'alignement des exigences peut entraîner deux adjacentes membres
de ne pas être affectés immédiatement les uns après les autres; ainsi pourrait
exigences pour l'espace pour la gestion des fonctions virtuelles (10.3) et
virtuel classes de base (10.1).

Autres que les variables de membre, une classe ou structure doit fournir de l'espace pour les variables de membre, les sous-objets de classes de base virtuelles fonction de gestion (par exemple, une table virtuelle), et de l'espacement et l'alignement de ces données. C'est jusqu'à la mise en œuvre, mais l'Itanium ABI spécification est un choix populaire. gcc et clang y adhérer (au moins à un certain degré).

http://mentorembedded.github.io/cxx-abi/abi.html#layout

L'Itanium ABI est bien sûr pas partie de la norme C++ et n'est pas contraignante. Pour obtenir plus de détails vous devez vous tourner votre réalisateur de la documentation et des outils. clang fournit un outil pour afficher la disposition de la mémoire de classes. Par exemple, les suivantes:

class VBase {
    virtual void corge();
    int j;
};

class SBase1 {
    virtual void grault();
    int k;
};

class SBase2 {
    virtual void grault();
    int k;
};

class SBase3 {
    void grault();
    int k;
};

class Class : public SBase1, SBase2, SBase3, virtual VBase {
public:
    void bar();
    virtual void baz();
    //virtual member function templates not allowed, thinking about memory
    //layout and vtables will tell you why
    //template<typename T>
    //virtual void quux();
private:
    int i;
    char c;
public:
    float f;
private:
    double d;
public:
    short s;
};

class Derived : public Class {
    virtual void qux();
};

int main() {
    return sizeof(Derived);
}

Après la création d'un fichier source qui utilise la disposition de la mémoire de la classe, clang va révéler la disposition de la mémoire.

$ clang -cc1 -fdump-record-layouts layout.cpp

La mise en page pour Class:

*** Dumping AST Record Layout
   0 | class Class
   0 |   class SBase1 (primary base)
   0 |     (SBase1 vtable pointer)
   8 |     int k
  16 |   class SBase2 (base)
  16 |     (SBase2 vtable pointer)
  24 |     int k
  28 |   class SBase3 (base)
  28 |     int k
  32 |   int i
  36 |   char c
  40 |   float f
  48 |   double d
  56 |   short s
  64 |   class VBase (virtual base)
  64 |     (VBase vtable pointer)
  72 |     int j
     | [sizeof=80, dsize=76, align=8
     |  nvsize=58, nvalign=8]

Plus sur ce bruit caractéristique peut être trouvé sur Eli Bendersky du blog:

http://eli.thegreenplace.net/2012/12/17/dumping-a-c-objects-memory-layout-with-clang/

gcc fournit un outil similaire, `-fdump-classe-hiérarchie". Pour la classe ci-dessus, il imprime (entre autres choses):

Class Class
   size=80 align=8
   base size=58 base align=8
Class (0x0x141f81280) 0
    vptridx=0u vptr=((& Class::_ZTV5Class) + 24u)
  SBase1 (0x0x141f78840) 0
      primary-for Class (0x0x141f81280)
  SBase2 (0x0x141f788a0) 16
      vptr=((& Class::_ZTV5Class) + 56u)
  SBase3 (0x0x141f78900) 28
  VBase (0x0x141f78960) 64 virtual
      vptridx=8u vbaseoffset=-24 vptr=((& Class::_ZTV5Class) + 88u)

Il n'a pas repris une à une les variables de membre (ou, au moins, je ne sais pas comment le faire), mais vous pouvez dire qu'il faudrait décalage entre 28 et 64, tout comme dans le cliquetis de mise en page.

Vous pouvez voir qu'une classe de base est désignée comme primary. Cela supprime la nécessité de l'ajustement de la this pointeur lorsque Class est consulté en tant que SBase1.

L'équivalent pour gcc:

$ g++ -fdump-class-hierarchy -c layout.cpp

L'équivalent pour Visual C++ est:

cl main.cpp /c /d1reportSingleClassLayoutTest_A

voir: https://blogs.msdn.microsoft.com/vcblog/2007/05/17/diagnosing-hidden-odr-violations-in-visual-c-and-fixing-lnk2022/

Comme indiqué précédemment, tous les détails sont compliquées, pénible à lire, et vraiment utile que pour les développeurs de compilateurs, et varie selon les compilateurs. Fondamentalement, chaque objet contient les éléments suivants (généralement disposés dans cet ordre):

1. Runtime type d'informations
2. Non Virtuelle des objets de base et de leurs données (probablement dans le but de déclaration).
3. Variables de membre
4. Virtuel des objets de base et de leurs données (Probablement dans certains arborescence DFS ordre de recherche).

Ces éléments de données peuvent ou peuvent ne pas être rembourré pour faire de la mémoire de l'alignement plus facile etc. Caché dans le runtime type d'informations est des trucs sur le type, la v-tableaux virtuel pour les parents des classes, etc, tout ce qui est compilateur spécifique.

Quand il s'agit de moulages, reinterpret_cast change simplement le C++ type de données de la flèche et ne fait rien d'autre, alors vous feriez mieux d'être sûr que vous savez ce que vous faites quand vous l'utilisez, sinon, vous êtes responsable de gâcher les choses mal. dynamic_cast n'très près la même chose qu'static_cast (dans la modification du pointeur) sauf qu'il utilise le moteur d'exécution type d'informations afin de déterminer si elle peut se convertir en un type donné, et comment le faire. Encore une fois, tout ce qui est compilateur spécifique. Notez que vous ne pouvez pas dynamic_cast un void* parce qu'il a besoin de savoir où trouver de l'exécution des informations de type, donc il peut faire tous ses merveilleux exécution des contrôles.