Nachlaufendes Padding in C/C++ in verschachtelten Strukturen – ist es notwendig?

Das ist eher eine theoretische Frage. Ich bin mit der Funktionsweise von Padding und Trailing Padding vertraut.

struct myStruct{
    uint32_t x;
    char*    p;
    char     c;
};

// myStruct layout will compile to
// x:       4 Bytes
// padding: 4 Bytes
// *p:      8 Bytes
// c:       1 Byte
// padding: 7 Bytes
// Total:   24 Bytes

Danach muss noch gepolstert werden xdamit *p ausgerichtet ist, und danach muss eine nachlaufende Polsterung vorhanden sein c sodass die gesamte Strukturgröße durch 8 teilbar ist (um die richtige Schrittlänge zu erhalten). Aber betrachten Sie dieses Beispiel:

struct A{
    uint64_t x;
    uint8_t  y;
};

struct B{
    struct A myStruct;
    uint32_t c;
};

// Based on all information I read on internet, and based on my tinkering
// with both GCC and Clang, the layout of struct B will look like:
// myStruct.x:       8 Bytes
// myStruct.y:       1 Byte
// myStruct.padding: 7 Bytes
// c:                4 Bytes
// padding:          4 Bytes
// total size:       24 Bytes
// total padding:    11 Bytes
// padding overhead: 45%

// my question is, why struct A does not get "inlined" into struct B,
// and therefore why the final layout of struct B does not look like this:
// myStruct.x:       8 Bytes
// myStruct.y:       1 Byte
// padding           3 Bytes
// c:                4 Bytes
// total size:       16 Bytes
// total padding:    3 Bytes
// padding overhead: 19%

Beide Layouts erfüllen die Ausrichtungen aller Variablen. Beide Layouts haben die gleiche Reihenfolge der Variablen. In beiden Layouts struct B hat die richtige Schrittlänge (teilbar durch 8 Bytes). Der einzige Unterschied (neben 33 % kleinerer Größe) ist das struct A hat in Layout 2 keine korrekte Schrittlänge, aber das sollte keine Rolle spielen, da es eindeutig kein Array von gibt struct As.

Ich habe dieses Layout in GCC mit -O3 und -g überprüft, struct B hat 24 Bytes.

Meine Frage ist – gibt es einen Grund, warum diese Optimierung nicht angewendet wird? Gibt es eine Layoutanforderung in C/C++, die dies verbietet? Oder fehlt mir ein Compilation-Flag? Oder ist das ein ABI-Ding?

EDIT: Beantwortet.

1. Siehe Antwort von @dbush, warum der Compiler dieses Layout nicht selbst ausgeben kann.
2. Das folgende Codebeispiel verwendet GCC-Pragmas packed und aligned (wie von @jaskij vorgeschlagen), um das optimiertere Layout manuell zu erzwingen. Struktur B_packed hat nur 16 Bytes statt 24 Bytes (beachten Sie, dass dieser Code Probleme verursachen kann/langsam läuft, wenn ein Array von Strukturen vorhanden ist B_packedseien Sie sich bewusst und kopieren Sie diesen Code nicht blind):

struct __attribute__ ((__packed__)) A_packed{
    uint64_t x;
    uint8_t  y;
};

struct __attribute__ ((__packed__)) B_packed{
    struct A_packed myStruct;
    uint32_t c __attribute__ ((aligned(4)));
};

// Layout of B_packed will be
// myStruct.x:       8 Bytes
// myStruct.y:       1 Byte
// padding for c:    3 Bytes
// c:                4 Bytes
// total size:       16 Bytes
// total padding:    3 Bytes
// padding overhead: 19%

Gibt es einen Grund, warum diese Optimierung nicht angewendet wird?

Wenn dies erlaubt wäre, wäre der Wert von sizeof(struct B) wäre zweideutig.

Angenommen, Sie haben Folgendes getan:

struct B b;
struct A a = { 1, 2 };
b.c = 0x12345678;
memcpy(&b.myStruct, &a, sizeof(struct A));

Sie würden den Wert von überschreiben b.c.

Polsterung wird verwendet, um die Ausrichtung zu erzwingen. Wenn Sie nun ein Array von struct myStruct haben, dann gibt es eine Regel, dass Array-Elemente ohne Auffüllung aufeinander folgen. In Ihrem Fall wäre ohne Auffüllen innerhalb von myStruct nach dem letzten Feld das zweite myStruct in einem Array nicht richtig ausgerichtet. Daher ist es notwendig, dass sizeof(myStruct) ein Vielfaches der Ausrichtung von myStruct ist, und dafür benötigen Sie möglicherweise genügend Polsterung am Ende.