Warum behandeln Compiler (z. B. gcc) auf diese Weise das Speicherlayout abgeleiteter Klassen?

8

Hier ist mein cpp-Code.

%Vor%

Die Ausgabe des Programms (in gcc) lautet:

%Vor%

Dieser Ausgang verwirrt mich sehr.

Ich weiß, dass die Ausrichtung der Grund dafür sein kann, dass Größe von (A) gleich 8 ist. ( sizeof(int) + sizeof(char) + 3 bytes padding )

Und ich nehme auch an, dass die Erweiterung der Größe von (B) ( sizeof(B) == sizeof(A) + sizeof(char) + 3 bytes padding ) eine Überlappung beim Kopieren verhindert. (Ist das richtig?)

Aber was ich wirklich nicht weiß, warum die Größe von (B) gleich der Größe von (C) ist.

Vielen Dank.

    
Wizmann 24.05.2014, 05:58
quelle

1 Antwort

13

Sowohl GCC als auch Clang folgen dem Itanium C ++ ABI -Dokument, das Folgendes angibt:

... Implementierungen können Objekte im Tail-Padding einer beliebigen Klasse frei zuweisen, die in C ++ 98 kein POD gewesen wäre

class A ist POD, daher kann der Compiler keine Inhalte in seinen Padding einfügen. class B ist kein POD, daher kann der Compiler das Padding innerhalb des Basisklassenlayouts für Mitglieder abgeleiteter Objekte erneut verwenden. Die Grundidee dabei war, dass das C ++ - Klassenlayout das entsprechende C-Struct-Layout für POD-Typen widerspiegeln sollte, für andere Klassen gibt es jedoch keine Einschränkungen. Da sich die Bedeutung von "POD" mehrfach geändert hat, wird explizit die Definition aus C ++ 98 verwendet.

BEARBEITEN: Über die Gründe. POD-Typen sind sehr einfache Klassen, die als struct in C implementiert werden können. Für diese Typen sollte das Layout identisch mit dem Layout sein, das ein C-Compiler erstellen würde. Insbesondere wollen sie C-Tools wie memcpy für A erlauben. Wenn char b; innerhalb der Auffüllung von A wäre, würde memcpy es zerstören.

    
pentadecagon 24.05.2014, 07:11
quelle

Tags und Links