sizeof(A): 8
3 bytes in the array, 1 byte padding, 4 bytes for the vptr (pointer to the vtable)
sizeof(B): 12
A subobject: 8, 3 bytes for the extra array, 1 byte padding
sizeof(C): 16
This is probably the surprising one for you...
A subobject: 8, 3 bytes for the extra array, 1 byte padding, 4 bytes pointer to A
Whenever you have virtual inheritance, the location of the virtual base subobject with respect to the start of the complete type is unknown, so an extra pointer is added to the original object to track where the virtual base is. Consider this example:
struct A {};
struct B : virtual A {};
struct C : virtual A {};
struct D : B, C {};
The location of A
with respect to the start of the B
object when the complete type is a B
can be different than the location of the A
subobject of B
when it is part of the final object D
. If this is not obvious, assume that the relative location is the same, and check whether the relative location of A
with respect to C
in a C
final object or a C
subobject in D
can also be maintained.
As for the last example, I don't quite feel like analyzing it... but you can read the Itanium C++ ABI for a concrete implementation of the C++ object model. All other implementations don't differ much.
Last example:
sizeof(D): 32
D contains a B subobject (12), and a C subobject (16), plus an additional array of size 3 and one extra bit of padding 1.
In this particular case, the question that could come up is why are there two A
subobjects if C
inherits virtually from A
, and the answer is that virtual base means that the object is willing to share this base with any other type in the hierarchy that is also willing to share it. But in this case B
is not willing to share it's A
subobject, so C
needs it's own.
You should be able to track this by adding logs to the constructors at the different levels. In the case of A
have it take a value in the compiler and pass different values from each extending class.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…