Pourquoi l'optimisation de base vide est-elle interdite lorsque la classe de base vide est également une variable membre?

L'optimisation de la base vide est excellente. Cependant, il est livré avec la restriction suivante:

L'optimisation de base vide est interdite si l'une des classes de base vide est également le type ou la base du type du premier membre de données non statique, car les deux sous-objets de base du même type doivent avoir des adresses différentes dans la représentation d'objet du type le plus dérivé.

Pour expliquer cette restriction, considérez le code suivant. Le static_assertéchouera. Alors que la modification de Fooou Barde hériter à la place Base2évitera l'erreur:

#include <cstddef>

struct Base  {};
struct Base2 {};

struct Foo : Base {};

struct Bar : Base {
    Foo foo;
};

static_assert(offsetof(Bar,foo)==0,"Error!");

Je comprends parfaitement ce comportement. Ce que je ne comprends pas, c'est pourquoi ce comportement particulier existe . Il a évidemment été ajouté pour une raison, car il s'agit d'un ajout explicite et non d'un oubli. Quelle en est la raison?

En particulier, pourquoi les deux sous-objets de base devraient-ils avoir des adresses différentes? Dans ce qui précède, Barest un type et fooest une variable membre de ce type. Je ne vois pas pourquoi la classe de base Barimporte pour la classe de base du type de foo, ou vice-versa.

En effet, je ne sais quoi, je m'attendrais à ce que ce &foosoit la même que l'adresse de l' Barinstance qui la contient - comme cela doit être dans d'autres situations ⁽¹⁾ . Après tout, je ne fais rien d'extraordinaire avec l' virtualhéritage, les classes de base sont vides malgré tout, et la compilation avec Base2montre que rien ne casse dans ce cas particulier.

Mais il est clair que ce raisonnement est incorrect d'une manière ou d'une autre, et il existe d'autres situations où cette limitation serait requise.

Disons que les réponses devraient être pour C ++ 11 ou plus récent (j'utilise actuellement C ++ 17).

_{^{(1) Remarque: EBO a été mis à niveau en C ++ 11, et en particulier est devenu obligatoire pour StandardLayoutTypes (bien que Bar, ci-dessus, ce ne soit pas a StandardLayoutType).}}

Ok, il semble que je me sois trompé tout le temps, car pour tous mes exemples, il doit exister une table virtuelle pour l'objet de base, ce qui empêcherait au départ l'optimisation de base vide. Je vais laisser les exemples tenir car je pense qu'ils donnent des exemples intéressants de la raison pour laquelle les adresses uniques sont normalement une bonne chose à avoir.

Après avoir étudié tout cela plus en profondeur, il n'y a aucune raison technique de désactiver l'optimisation de classe de base vide lorsque le premier membre est du même type que la classe de base vide. C'est juste une propriété du modèle objet C ++ actuel.

Mais avec C ++ 20, il y aura un nouvel attribut [[no_unique_address]]qui indique au compilateur qu'un membre de données non statique peut ne pas avoir besoin d'une adresse unique (techniquement parlant, elle chevauche potentiellement [intro.object] / 7 ).

Cela implique que (c'est moi qui souligne)

Le membre de données non statique peut partager l'adresse d'un autre membre de données non statique ou celle d'une classe de base , [...]

par conséquent, on peut "réactiver" l'optimisation de classe de base vide en donnant l'attribut au premier membre de données [[no_unique_address]]. J'ai ajouté un exemple ici qui montre comment cela (et tous les autres cas auxquels je pourrais penser) fonctionne.

Mauvais exemples de problèmes à travers ce

Puisqu'il semble qu'une classe vide peut ne pas avoir de méthodes virtuelles, permettez-moi d'ajouter un troisième exemple:

int stupid_method(Base *b) {
  if( dynamic_cast<Foo*>(b) ) return 0;
  if( dynamic_cast<Bar*>(b) ) return 1;
  return 2;
}

Bar b;
stupid_method(&b);  // Would expect 0
stupid_method(&b.foo); //Would expect 1

Mais les deux derniers appels sont les mêmes.

Anciens exemples (ne répondent probablement pas à la question car les classes vides peuvent ne pas contenir de méthodes virtuelles, semble-t-il)

Considérez dans votre code ci-dessus (avec des destructeurs virtuels ajoutés) l'exemple suivant

void delBase(Base *b) {
    delete b;
}

Bar *b = new Bar;
delBase(b); // One would expect this to be absolutely fine.
delBase(&b->foo); // Whoaa, we shouldn't delete a member variable.

Mais comment le compilateur doit-il distinguer ces deux cas?

Et peut-être un peu moins artificiel:

struct Base { 
  virtual void hi() { std::cout << "Hello\n";}
};

struct Foo : Base {
  void hi() override { std::cout << "Guten Tag\n";}
};

struct Bar : Base {
    Foo foo;
};

Bar b;
b.hi() // Hello
b.foo.hi() // Guten Tag
Base *a = &b;
Base *z = &b.foo;
a->hi() // Hello
z->hi() // Guten Tag

Mais les deux derniers sont les mêmes si nous avons une optimisation de classe de base vide!