Das Musterbeispiel sieht doch immer so aus:

template <typename T, typename Alloc>
class vector : Alloc {
  T *data, *data_end, *storage_end;
  Alloc& get_alloc() { return static_cast<Alloc&>(*this); }
};

Wenn Alloc leer ist, ist hier alles bestens, weil dann ist data an erster Stelle und das will man aus Performanzgründen. Sobald Alloc aber nicht mehr leer ist, wird data nach hinten verschoben und das hat dann negative Auswirkungen auf die Performanz.

Es gibt zwar Hacks, aber IMHO gibt es keinen standardkonformen Weg, mit EBO zu garantieren, dass Alloc am Ende der Memberliste steht. Bringt EBO deshalb in der Praxis etwas?

eber schrieb:

Es gibt zwar Hacks, aber IMHO gibt es keinen standardkonformen Weg, mit EBO zu garantieren, dass Alloc am Ende der Memberliste steht. Bringt EBO deshalb in der Praxis etwas?

Wo willst du Alloc denn nun haben und warum, obwohl es doch gar nicht "da" ist?

eber schrieb:

Bringt EBO deshalb in der Praxis etwas?

Und wie! Es macht dass du all die schicken durchdesignten Bibliotheken nutzen kannst, ohne dass jeder popelige Smartpointer eine sizeof von > 1000 hat.

Inwiefern hat es Auswirkungen auf die Performance, wenn data weiter hinten steht?

vec[n]
ist, falls data vorne steht, *(&vec + n)
ansonsten *(&vec + offsetof(vec.data) + n)
also eine Addition mehr.

@SeppJ: Es geht um den Fall, dass Alloc doch da ist.

@SeppJ: Es geht um den Fall, dass Alloc doch da ist.

Dann greift EBO nicht und die Frage ist hinfällig.

Oder ist deine Frage, ob EBO etwas bringt, wenn EBO nicht greift? Antwort: Nein.

Die Frage: Lohnt sich EBO wirklich?

Allokatoren sind (Prä-C++11) in der Regel leer. Wer sich nicht daran hält, weiß wohl (hoffentlich) was er da tut. Dein vermuteter Performancenachteil ist daher nur hypothetisch. Selbst wenn dieser Fall einträte, wäre der Nachteil winzig. Dafür ist der mögliche Gewinn riesig!

Wenn du dir wirklich Sorgen machst, kannst du mitteln Templatemagie auch zwei unterschiedliche Versionen schreiben, einmal mit Vererbung, einmal mit Komposition.

ipsec schrieb:

Inwiefern hat es Auswirkungen auf die Performance, wenn data weiter hinten steht?

vec[n]
ist, falls data vorne steht, *(&vec + n)
ansonsten *(&vec + offsetof(vec.data) + n)
also eine Addition mehr.

Nope, ist es nicht. Da fehlt eine Indirektion, der vector enthält lediglich einen Pointer auf den Speicher. Abgesehen davon, verfügen die meisten CPUs wohl über entsprechende Addressierungsmodi, sodass das offsetof da kaum bis praktisch bzw. sogar tatsächlich gar keinen Unterschied macht...