I think sizeof(Base) should be 12. Why is it 16?
Without the virtual function, I get 4 and 8.
class Base{
public:
int i;
virtual void Print(){cout<<"Base Print";}
};
class Derived:public Base{
public:
int n;
virtual void Print(){cout<<"Derived Print";}
};
int main(){
Derived d;
cout<<sizeof(Base)<<","<<sizeof(d);
return 0;
}
expected result：12，16
actual result：16，16
why sizeof(Base) is not different of sizeof(Derived)
Because of the alignment introduced by the compiler.
That is architecture-dependent, but for sake of simplicity, I am going to assume we are referring a 64-bit architecture.
Scenario 64 bit / Clang 8.0.
The alignment of the type Base is 8 bytes:
alignOfBase(): # #alignOfBase()
mov eax, 8
ret
The layout of Base is composed by the variable member (int) and the virtual table (vtptr).
If we assume a "common" architecture where:
int is 4 bytes size.
vtptr is a pointer. On a 64 bit architecture is 8 bytes size.
We should have a sum of 4 + 8 = 12, as you expect.
However, we need to remember the alignment of Base is 8 bytes. Therefore consecutive Base types should be stored in location multiple of 8.
In order to guarantee that, the compiler introduces padding for Base. That's why Base is 16 bytes size.
For example, if we consider 2 consecutive Base (base0 and base1) without padding:
0: vtptr (base 0) + 8
8: int (base 0) + 4
12: vtptr (base 1) + 8 <--- Wrong! The address 12 is not multiple of 8.
20: int (base 1) + 4
With padding:
0: vtptr (base 0) + 8
8: int (base 0) + 4+4 (4 padding)
16: vtptr (base 1) +8 <--- Fine! The adress 16 is multiple of 8.
24: int (base 1) +4+4 (4 padding)
The same story is for Derived type.
The layout of Derived should be: vtptr + int + int, that is, 8 + 4 + 4 = 16.
The alignment of Derived is 8 too:
alignOfDerived(): # #alignOfDerived()
mov eax, 8
ret
Indeed, in this case, there is no need to introduce padding in order to keep the Derived aligned with the memory. The layout size will be the same as the real size.
0: vtptr (Derived 0)
8: int (Derived 0)
12: int (Derived 0)
16: vtptr (Derived 1) <---- Fine. 16 is multiple of 8.
24: int (Derived 1)
28: int (Derived 1)
This happens due to compiler deciding to align your classes.
If you want (or need) structs or classes to have their "real" sizes, you can use #pragma pack(1) like this:
#pragma pack(push, 1) // Set packing to 1 byte and push old packing value to stack
class Base{
public:
int i;
virtual void Print(){cout<<"Base Print";}
};
class Derived:public Base{
public:
int n;
virtual void Print(){cout<<"Derived Print";}
};
int main(){
Derived d;
cout<<sizeof(Base)<<","<<sizeof(d);
return 0;
}
#pragma pack(pop) // restore old packing value
Related
class A {
int a;
public:
virtual ~A() {}
};
class B : public A {
int b;
};
int main(int argc, char* argv[])
{
cout << sizeof(B) << endl;
return 0;
}
(Based on 64bits program), I notice the differences of the values under Visual Studio and gcc, respectively are 24 and 16.
By analyzing, the virtual table costs 8 bytes, int a and int b respectively is 4 bytes. So the alignment for VS is 8 but for gcc is 4.
What does cause the difference, how does the C++ standard say?
struct C {
char a;
int b;
char c;
};
int main(int argc, char* argv[])
{
cout << sizeof(C) << endl;
return 0;
}
Moreover, under VS, the size of this struct is 12 that implies the alignment is 4, different from the alignment for class B under VS.
Why?
You will find that alignof(A) == 8 && sizeof(A) == 16 on both compilers, laid out as 8 bytes for a pointer, 4 bytes for int A::a, and 4 bytes of padding.
Since A is a base class, it is a potentially overlapping subobject of any B objects. This means that the padding can be reused.
gcc/clang (More specifically, things that follow the Itanium ABI) have to allocate int B::b into the 4 bytes of padding in the base class, so sizeof(B) is also 16 (but alignof(B) == 8 still).
MSVC (and clang compiling for Windows) follow a different ABI, which happens to not reuse the tail padding, so the layout of B looks like 8 bytes for a pointer, 4 bytes for int A::a, 4 bytes of padding (inherited from A), 4 bytes for int B::b, and 4 more bytes of padding.
As for your last questions, typically vtables are implemented as a pointer stored at the front of each object. This pointer will usually have the size an alignment requirement of 8 on a 64 bit platform. C would be comparable if it looked like:
struct C {
void* p;
char a;
// 3 bytes padding
int b;
char c;
// 7 bytes padding to alignment of 8
};
static_assert(sizeof(C) == 24 && alignof(C) == 8);
With the other's help, I finally figure it out.
alignof(B) under VS and GCC are same which is 8.
1. Why sizeof(B) are different?
Because they store the virtual function pointer (vptr) at different places, for VS at beginning and for GCC at the end. Something like this,
//B for VS
class B{
class A{
void* vptr;
int a;
};
int b;};
//B for GCC
class B{
int a;
int b;
void* vptr;
};
For VS, sizeof(B) = sizeof(vptr) + (sizeof(int a) padding to 8) + (sizeof(int b) padding to 8) = 24.
For GCC, sizeof(B) = (sizeof(int a)+sizeof(int b) padding to 8) + sizeof(vptr) = 16.
2. Why alignof(C) is 4?
Because there is virtual function in struct C. If you add virutal ~C(){} for C, alignof(C) would be 8 either.
I'm trying to understand struct and class padding in depth, so I devised an example I considered more challenging than many of the examples I found in tutorials on the topic. I compiled it in an x64 machine with g++, without enabling any code optimization. My code is as follows:
class Example
{
private:
long double foobar; // 10 bytes + 6 padded bytes as double follows
double barfoo; // 8 bytes + 8 padded bytes
static float barbar; // didn't count as it's a static member
float *fooputs; // 8 bytes + 8 padded bytes
int footsa; // 4 bytes, stored in the padded portion of float
char foo; // 1 byte, stored in the padded portion of float
public:
int function1(int foo) { return 1; }
void function2(int bar) { foobar = bar; }
};
int main()
{
std::cout << sizeof(Example) << std::endl; // 48 bytes
return 0;
}
Although I see that the size of Example is 48 bytes, I expected it to be 37 bytes. The argumentation on my expectation is as follows:
foobar needs 10 bytes. As double follows, 6 more bytes are needed for padding.
barfoo needs 8 bytes, as it's a double. No need for padding, as mod(16,8) == 0
*fooputs needs 8 bytes, as it's a pointer in an x64 architecture. No need for padding, as mod(24,8) == 0
footsa needs 4 bytes as an int. No need for padding, as mod(32,4) == 0
foo needs 1 byte as a char. No need for padding.
As the result is different that the expected, I tried to understand how C++ evaluated the size of Example to 48 bytes by commenting in and out class members. So, besides of the argumentation for foobar I assumed the justifications I'm writing in my inline comments for each member.
Could anyone explain me how the size is evaluated to 48 bytes and if my justifications are correct?
You forget about the final padding. sizeof returns a number of bytes between two adjacent members in an array. In your case, alignof(long double) is very likely 16, therefore each Example instance requires to be at 16-byte aligned address.
Consequently, if you have first instance of Example at a 16-bytes aligned address A, and then there are 37 bytes required by members, the next Example instance cannot be stored at A + 37 bytes, but it needs to be stored at A + k * 16. The smallest possible k that satisfies k * 16 >= 37 is 3. Which finally gives you the number of bytes between two Example instances in an array 3 * 16 = 48, which is exactly sizeof(Example).
#include <iostream>
class B
{
public:
virtual void f() {std::cout<<"HI";}
int x;
};
class A
{
public:
void f() {std::cout<<"HI";}
int x;
};
int main () {
A a;
B b;
std::cout<<sizeof(a)<<" "<<sizeof(b);
return 0;
}
The output is
4 16
I expected it to be 8 bytes longer - vptr pointer. But for what the rest 4 bytes is used?
I found quite many forum posts (all from some years ago) where people discussed that object from the class with vprt is 4 or 8 bytes longer. I checked also on online C++ shell - output there is the same.
It seems that the pointer to the table of pointers to virtual functions has a size of 8 bytes. So the class B is aligned to the boundary of 8 bytes that is it has 4 additional padding bytes.
This question already has an answer here:
Size of class with virtual function
(1 answer)
Closed 8 years ago.
Have a look at these 2 cases:
class A {
public:
int a;
A () { a = 10;}
void foo () {std::cout << "a = " << a << std::endl;}
};
Here sizeof(A) gives 4 bytes, which makes sense.
class A {
public:
int a;
A () { a = 10;}
virtual void foo () {std::cout << "a = " << a << std::endl;}
};
Here sizeof(A) gives 16 bytes as opposed to 12 bytes (4 + 8 for pointer).
Is there any explanation in terms of memory alignment for this ?
It's up to the compiler how virtual functions are implemented, but what's likely happening here is it wants/needs to align the 8-byte pointer to the virtual dispatch table on a multiple-of-8 memory address. Then there's either { 4 bytes a, 4 padding, 8 vdt pointer } or { 8 vdt pointer, 4 bytes a, 4 padding } - the latter's less obvious, but consider that arrays of A need to be contiguous and spaced per sizeof(A), so 12's rounded up to 16 given the 8-byte alignment.
FIRST in virtual dispatch table, visual functions need a pointer size , in 32 bits computer, the size of pointer is 4 bytes, int 64 bits it's 8 bytes. so I think your computer is 64 bits.
SECOND the sizeof(A) should consider the padding and memory alignment .
so 16 bytes is arranged like that: 4 bytes(int a) + 8 bytes(a virtual function pointer int 64 bits) + 4 bytes padding(because the max size of elements in A is the virtual function pointer which is 8 bytes, so the sizeof(A)should be the integral multiples of 8 bytes )
I encounter this problem when tackling with virtual inheritance. I remember that in a non-virtual inheritance hierarchy, object of sub-class hold an object of its direct super-class. What about virtual inheritance? In this situation, does object of sub-class hold an object of its super-class directly or just hold a pointer pointing to an object of its super-class?
By the way, why the output of the following code is:
sizeof(A): 8
sizeof(B): 20
sizeof(C): 20
sizeof(D): 36
Code:
#include <iostream>
using namespace std;
class A{
char k[ 3 ];
public:
virtual void a(){};
};
class B : public virtual A{
char j[ 3 ];
public:
virtual void b(){};
};
class C : public virtual A{
char i[ 3 ];
public:
virtual void c(){};
};
class D : public B, public C{
char h[ 3 ];
public:
virtual void d(){};
};
int main( int argc, char *argv[] ){
cout << "sizeof(A): " << sizeof( A ) << endl;
cout << "sizeof(B): " << sizeof( B ) << endl;
cout << "sizeof(C): " << sizeof( C ) << endl;
cout << "sizeof(D): " << sizeof( D ) << endl;
return 0;
}
Thanks in advance.
Kind regards.
The virtual base object is somewhere in the memory block that belongs to the object (the memory with size = sizeof(object)). Because several sub objects of different types can be combined in various ways but must share the same base object, a offset pointer is needed for each sub object to find out the virtual base object. Without virtual inheritance, the offset to find out the corresponding base object is fixed at compile time for each class type.
The sizeof values depend on your compiler and machine, but the following assumptions are very common:
assumption: pointer size is 4 bytes
assumption: class size is rounded up to multiple of 4 bytes
sizeof(A): 8 -> 1 pointer to vtable (virtual method)
+ 3 chars -> 4+3=7
-> round up to 8
sizeof(B): 20 -> 8 + 1 pointer to vtable (virtual method)
+ 1 offset pointer to virtual base
+ 3 chars -> 8 + 4 + 4 + 3 = 19
-> round up to 20
sizeof(C): 32 -> 20 + 1 pointer to vtable (virtual method)
+ 1 offset pointer to virtual base
+ 3 chars
-> 20 + 4 + 4 + 3 = 31 // this calculation refers to an older
-> round up to 32 // version of the question's example
// where C had B as base class
The calculations are guessed because the real calculation must exactly know how the compiler works.
Regards,
Oliver
More details why an extra offset pointer is needed:
Example:
class B : virtual public A {...};
class C : virtual public A {...};
class D1 : public B {...};
class D2 : public B, C {...};
possible memory layout for D1:
A
B
D1
possible memory layout for D2:
A
C
B
D2
in the second case sub object B needs another offset to find its base A
An object of type D2 consists of a memory block, where all the parent object parts are contained, i.e. the memory block for an object of type D2 has a section for the A member variables, the C member variables, the B member variables and the D2 member variables. The order of these sections is compiler dependent, but the example shows, that for multiple virtual inheritance a offset pointer is needed, that points within the object's total memory block to the virtual base object. This is needed because the methods of class B know only one this pointer to B and must somehow calculate where the A memory part is relative to the this pointer.
Calculation sizeof(D):
sizeof(D): 36 -> A:3 chars + A:vtable
+ B:3 chars + B:vtable + B:virtual base pointer
+ C:3 chars + C:vtable + C:virtual base pointer
+ D:3 chars + D:vtable
= 3 + 4
+ 3 + 4 + 4
+ 3 + 4 + 4
+ 3 + 4
= 36
The above calculation is probably wrong ;-) ...
I'm not sure whether the D part has its own vtable pointer or not (this is all highly compiler dependent).
I now think that it could be that the D part use the vtable pointer entry of its parent classes and that the 4 extra bytes are used for alignment each part (multiple of 8 bytes):
So this calculation is probably more correct:
sizeof(D): 36 -> A:3 chars + A:vtable + A:alignment
+ B:3 chars + B:vtable + B:virtual base pointer + B:alignment
+ C:3 chars + C:vtable + C:virtual base pointer + C:alignment
+ D:3 chars + D:alignment
= 3 + 4 + 1
+ 3 + 4 + 4 + 1
+ 3 + 4 + 4 + 1
+ 3 + 1
= 36
I see three point analysis for the above question
a. Virtual Inheritance
"Virtual inheritance is a mechanism whereby a class specifies that it is willing to share the state of its virtual base class. Under virtual inheritance, only one, shared base-class subobject is inherited for a given virtual base regardless of how many times the class occurs as a virtual base within the derivation hierarchy. The shared base-class subobject is called a virtual base class." ... From Lippman
Virtual inheritance only avoids duplicate sub-objects inherited from multiple inheritance. But this does not indicate in any way that the base class objects will not be sub-objects. On the contrary, the sub-object (atleast one copy would be present - I mean would be included in sizeof() operation) even during the virtual inheritance.
b. virtual function
Virtual function is for dynamic binding of member functions of objects involved in hierarchy. So even this does not have any significance towards sub-object arrangements.
c. Implementation of the sub-objects
This is totally compiler dependent, and for all reasons would be very difficult to determine - in its implementation. However, we can confirm that the sizeof() of the object would include the size of the base class (sub) objects also - and we can visualize them as having the base class object embedded in them.
Each object of the inherited function will definitely contain space for the sub-objects.
HTH
does object of sub-class hold an object of its super-class directly
Yes, that is how it works whether the inheritance is virtual or not. I would use the word "contain" vs. "hold" however.
If your hierarchy looked like this, with no virtual inheritances anywhere:
# W <--- base class
# / \
# X Y <--- subclasses of W
# \ /
# Z <--- most derived class
Then Z will have two copies of W. But if you make the X-->W and Y-->W inheritances virtual, then Z will only have one copy of W because Z's two superclasses share their common base class.
# W
# / \ <--- make these two virtual to eliminate duplicate W in Z.
# X Y
# \ /
# Z
In your example:
class A{...};
class B : public virtual A{...};
class C : public virtual B{...}; // Edit: OP's code had this typo when I answered
class D : public B, public C{...};
Having B inherit virtually from A isn't necessary. The only virtual inheritances you need are C-->B and D-->B, since that is where the diamond "merges" going up the inheritance hierarchy:
# What you have | What you want?
# A | A
# / | /
# /v | /
# / | /
# B | B
# / \ | / \
# /v \ | /v \v
# / \ | / \
# C ) | C )
# \ / | \ /
# \ / | \ /
# \ / | \ /
# D | D
Of course if you have other classes not shown that inherit from A as well as B, that changes things -- maybe the B-->A inheritance does need to be virtual if there is another diamond you didn't tell us about.
I remember that in a non-virtual inheritance hierarchy, object of sub-class hold an object of its direct super-class.
That is not correct. Several implementations are going to do it this way, but it's not defined that way by Standard C++. Standard C++ does not specify how any of these things are to be implemented.
Virtual Inheritance is used only for some cases of multiple inheritance where a derived class multiply inherits from two base classes which themselves inherit from a common base class. An example of this is the iostream library, where istream and ostream inherit from basic_ios, and iostream inherits from istream and ostream (and so one iostream would have two basic_ios without virtual inheritance).
Unless you are in this specific scenario, you should not use virtual inheritance.
What about virtual inheritance? In this situation, does object of sub-class hold an object of its super-class directly or just hold a pointer pointing to an object of its super-class?
That is implementation defined. You do not need to know nor should you ever make any assumptions about this. Suffice to say that there is a runtime penalty for virtual inheritance, which is why you should avoid it when it is not needed.
Compare:
struct A {
void *vptr; // offset 0 size 4 alignment 4
char k[3]; // offset 4 size 3 alignment 1
char unnamed_padding; // offset 7 size 1
// total size 8 alignment 4
};
// MS:
struct base_B {
void *vptr; // offset 0 size 4 alignment 4
char j[3]; // offset 4 size 3 alignment 1
char unnamed_padding; // offset 7 size 1
A &a_subobject; // offset 8 size 4 alignment 4
// total size 12 alignment 4
base_B (&a_subobject) :a_subobject(a_subobject) {}
};
struct B {
base_B b; // offset 0 size 12 alignment 4
A a_subobject; // offset 12 size 8 alignment 4
// total size 20 alignment 4
B () : b(a_subobject) {}
};
struct base_C {
void *vptr; // offset 0 size 4 alignment 4
char i[3]; // offset 4 size 3 alignment 1
char unnamed_padding; // offset 7 size 1
A &a_subobject; // offset 8 size 4 alignment 4
// total size 12 alignment 4
base_C (&a_subobject) : a_subobject(a_subobject) {}
};
struct C {
base_C c;
A a_subobject; // offset 12 size 8 alignment 4
// total size 20 alignment 4
C () : c(a_subobject) {}
};
struct D {
// no new vptr!
// base_B is used as primary base: b_subobject.vptr is used as vptr
base_B b_subobject; // offset 0 size 12 alignment 4
base_C c_subobject; // offset 12 size 12 alignment 4
char h[3]; // offset 24 size 3 alignment 1
char unnamed_padding; // offset 27 size 1
A a_subobject; // offset 28 size 8 alignment 4
// total size 36 alignment 4
D (): b_subobject(a_subobject), c_subobject(a_subobject) {}
};
// GCC:
struct base_B {
void *vptr; // offset 0 size 4 alignment 4
char j[3]; // offset 4 size 3 alignment 1
char unnamed_padding; // offset 7 size 1
// total size 8 alignment 4
};
struct B {
base_B b; // offset 0 size 12 alignment 4
A a_subobject; // offset 8 size 8 alignment 4
// total size 16 alignment 4
};
struct base_C {
void *vptr; // offset 0 size 4 alignment 4
char i[3]; // offset 4 size 3 alignment 1
char unnamed_padding; // offset 7 size 1
// total size 8 alignment 4
};
struct C {
base_C b; // offset 0 size 12 alignment 4
A a_subobject; // offset 8 size 8 alignment 4
// total size 16 alignment 4
};
struct D {
// no new vptr!
// base_B is used as primary base: b_subobject.vptr is used as vptr
base_B b_subobject; // offset 0 size 8 alignment 4
base_C c_subobject; // offset 8 size 8 alignment 4
char h[3]; // offset 16 size 3 alignment 1
char unnamed_padding; // offset 19 size 1
A a_subobject; // offset 20 size 8 alignment 4
// total size 24 alignment 4
};