Pourquoi la définition de la "disposition standard" de la POD du C++11 est-elle telle qu'elle est ?

Question

Je me penche sur la nouvelle définition assouplie de la POD en C++11 (section 9.7)

Une classe de mise en page standard est une classe qui :

• n'a pas de membres de données non statiques de type classe de présentation non standard (ou tableau de tels types) ou référence,
• n'a pas de fonctions virtuelles (10.3) ni de classes de base virtuelles (10.1),
• a le même contrôle d'accès (article 11) pour tous les membres de données non statiques,
• n'a pas de classes de base de mise en page non standard,
• soit n'a pas de membres de données non statiques dans la classe la plus dérivée et au plus une classe de base avec des membres de données non statiques ou n'a pas de classes de base avec des membres de données non statiques, et
• n'a pas de classes de base du type même type que le premier élément de données non statique .

J'ai souligné les éléments qui m'ont surpris.

Que se passerait-il si nous tolérions que les membres des données soient soumis à des contrôles d'accès variables ?

Que se passerait-il si le premier membre des données était également une classe de base ?

struct Foo {};
struct Good : Foo {int x; Foo y;};
struct Bad  : Foo {Foo y; int x;};

Je reconnais qu'il s'agit d'une construction bizarre, mais pourquoi devrait-on Bad être interdites, mais pas Good ?

Enfin, que se passerait-il si plus d'une classe constitutive avait des membres de données ?

Answer 1

Vous êtes autorisé à convertir l'adresse d'un objet de la classe de présentation standard en un pointeur sur son premier membre et à revenir par l'un des paragraphes suivants, ce qui est également souvent le cas en C :

struct A { int x; };
A a;

// "px" is guaranteed to point to a.x
int *px = (int*) &a;

// guaranteed to point to a
A *pa = (A*)px; 

Pour que cela fonctionne, le premier membre et l'objet complet doivent avoir la même adresse (le compilateur ne peut pas ajuster le pointeur int d'un octet parce qu'il ne peut pas savoir s'il s'agit d'un membre d'un objet de type A ou non).

Enfin, que se passerait-il si plus d'une classe constitutive avait des membres de données ?

Au sein d'une classe, les membres sont attribués par adresses croissantes selon l'ordre de déclaration. Cependant, le C++ ne dicte pas l'ordre d'allocation des membres de données entre les classes. Si la classe dérivée et la classe de base ont toutes deux des membres de données, la norme ne définit pas d'ordre pour leurs adresses, afin de donner à l'implémentation une flexibilité totale dans l'agencement de la mémoire. Mais pour que la distribution ci-dessus fonctionne, il faut savoir quel est le "premier" membre dans l'ordre d'allocation !

Que se passerait-il si le premier membre des données était également une classe de base ?

Si la classe de base a le même type que le premier membre de données, les implémentations qui placent les classes de base avant les objets de la classe dérivée en mémoire devraient avoir un octet de remplissage avant les membres de données de l'objet de la classe dérivée en mémoire (la classe de base aurait une taille de un), pour éviter d'avoir la même adresse pour la classe de base et le premier membre de données (en C++, deux objets distincts du même type ont toujours des adresses différentes). Mais cela rendrait à nouveau impossible le moulage de l'adresse de l'objet de la classe dérivée vers le type de son premier membre de données.

Answer 2

Il s'agit essentiellement d'une question de compatibilité avec C++03 et C :

• même contrôle d'accès - Les implémentations C++03 sont autorisées à utiliser les spécificateurs de contrôle d'accès pour réorganiser les (groupes de) membres d'une classe, par exemple pour mieux l'empaqueter.
• plus d'une classe dans la hiérarchie avec des membres de données non statiques - C++03 ne dit pas où les classes de base sont situées, ou si le remplissage est éludé dans les sous-objets de la classe de base qui seraient présents dans un objet complet du même type.
• classe de base et premier membre du même type - en raison de la deuxième règle, si le type de la classe de base est utilisé pour un membre de données, il est alors doit soit une classe vide. De nombreux compilateurs mettent en œuvre l'optimisation de la classe de base vide, de sorte que ce que dit Andreas sur le fait que les sous-objets ont la même adresse serait vrai. Je ne suis pas sûr de ce qui, dans les classes à structure standard, fait qu'il est mauvais pour le sous-objet de la classe de base d'avoir la même adresse qu'un premier membre de données du même type, mais que cela n'a pas d'importance lorsque le sous-objet de la classe de base a la même adresse qu'un premier membre de données d'un type différent. [C'est parce que différents objets du même type ont des adresses différentes, même s'il s'agit de sous-objets vides. Merci à Johannes]

C++0x probablement pourrait a défini que ces éléments sont également des types de mise en page standard, auquel cas il définit également la manière dont ils sont présentés, dans la même mesure que pour les types de mise en page standard. La réponse de Johannes va plus loin, regardez son exemple d'une belle propriété des classes de présentation standard avec laquelle ces choses interfèrent.

Mais si c'était le cas, certaines implémentations seraient obligées de modifier la disposition des classes pour répondre aux nouvelles exigences, ce qui est gênant pour la compatibilité des structures entre les différentes versions de ce compilateur avant et après C++0x. Cela rompt l'ABI du C++, fondamentalement.

D'après ce que j'ai compris de la définition de la mise en page standard, on a examiné quelles exigences de la POD pouvaient être assouplies sans compromettre les mises en œuvre existantes. Je suppose donc, sans vérifier, que les exemples ci-dessus sont des exemples où une implémentation existante de C++03 hace utiliser la nature non POD de la classe pour faire quelque chose d'incompatible avec la mise en page standard.

Answer 3

Que se passerait-il si nous tolérions que les membres des données soient soumis à des contrôles d'accès variables ?

Le langage actuel stipule que le compilateur ne peut pas réorganiser les membres soumis au même contrôle d'accès. Par exemple :

struct x
{
public:
    int x;
    int y;
private:
    int z;
};

Ici, x doit être alloué avant y, mais il n'y a aucune restriction sur z par rapport à x et y.

struct y
{
public:
    int x;
public:
    int y;
};

La nouvelle formulation prévoit que y est toujours un POD malgré les deux public s. Il s'agit en fait d'un assouplissement des règles.

Answer 4

Pour quelle raison Bad n'est pas autorisé, permettez-moi de citer un article que j'ai trouvé :

Cela garantit que deux sous-objets qui ont le même s appartenant au même objet le plus dérivé ne sont pas alloués à la même adresse. même adresse.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html

Answer 5

D'après le point 5, il semble que les deux ne soient pas compatibles puisque la classe la plus dérivée a un membre de données non statique (l'int), elle ne peut pas avoir une classe de base avec un membre de données non statique.

Je l'entends comme suit : "seule une classe "de base" (c'est-à-dire la classe elle-même ou l'une des classes dont elle hérite) peut avoir des membres de données non statiques".