0I know there is no need for the knowledge of memory layout for a normal day-to-day development of C++. However, when someone goes in the bit/byte level of C++, he needs to look for such discussion.
To state the problem, let us have a class hierarchy like the following.
class A {
public:
virtual void funA()
{}
virtual ~A(){}
public:
int a;
};
class B {
public:
virtual void funB(){};
virtual ~B(){}
public:
int b;
};
class C : public A, public B {
public:
int c;
};
Now if we run this app using a GCC compiler on a 64 bit machine and see the sizeof() these classes, we will see A will be 16 byte, B will be 16 byte and C will be of 32 bytes . So lets discuss how these numbers have come.
To start with the discussion, i need to throw some lights about how polymorphic behavior in C++ using virtual functions is tackeled by a compiler. Whenever there is a class having virtual function, the compiler will generate a VTABLE of that class and all the objects of that class will use that VTABLE. VTABLE is nothing but a TABLE having pointers to the virtual functions in a class hierarchy. And whenever there is a VTABLE, the compiler will silently add a pointer in the beginning of an object of the class. This pointer is called vptr and it actually points to the beginning of the VTABLE.
So in the following case two VTABLES will be created (each for class A and B).
Hence the size of an object of class A will be size-of-a-pointer(vptr) + size-of-int. So for a 64 bit architecture (where a pointer is 8 byte long) it will be 8 + 4 = 12. If this is the case, then how come sizeof(A) shows 16. Here comes the concept of Alignment and Padding bits.
Here is an excerpt from Wiki about alignment.
"A memory address a, is said to be n-byte aligned when a is a multiple of n bytes (where n is a power of 2). In this context a byte is the smallest unit of memory access, i.e. each memory address specifies a different byte. An n-byte aligned address would have log2(n) least-significant zeros when expressed in binary.
The alternate wording b-bit aligned designates a b/8 byte aligned address (ex. 64-bit aligned is 8 bytes aligned).
A memory access is said to be aligned when the datum being accessed is n bytes long and the datum address is n-byte aligned. When a memory access is not aligned, it is said to be misaligned. Note that by definition byte memory accesses are always aligned.
A memory pointer that refers to primitive data that is n bytes long is said to be aligned if it is only allowed to contain addresses that are n-byte aligned, otherwise it is said to be unaligned. A memory pointer that refers to a data aggregate (a data structure or array) is aligned if (and only if) each primitive datum in the aggregate is aligned.
Note that the definitions above assume that each primitive datum is a power of two bytes long. When this is not the case (as with 80-bit floating-point on x86) the context influences the conditions where the datum is considered aligned or not.
Data structures can be stored in memory on the stack with a static size known as bounded or on the heap with a dynamic size known as unbounded."
To maintain the alignment, compiler inserts padding bits in the compiled code of a structure/class object.
"Although the compiler (or interpreter) normally allocates individual data items on aligned boundaries, data structures often have members with different alignment requirements. To maintain proper alignment the translator normally inserts additional unnamed data members so that each member is properly aligned. In addition the data structure as a whole may be padded with a final unnamed member. This allows each member of an array of structures to be properly aligned. .... ....
Padding is only inserted when a structure member is followed by a member with a larger alignment requirement or at the end of the structure" - Wiki
To get more info about how GCC does it, please look at
http://www.delorie.com/gnu/docs/gcc/gccint_111.html
and search for the text "basic-align".
Now lets come to this problem:
Using the example class, i have created this program for a GCC compiler running on a 64 bit Ubuntu.
int main() {
A objA;
C objC;
cout<<sizeof(void*)<<endl;
cout<<sizeof(int)<<endl;
cout<<sizeof(A)<<endl;
cout<<sizeof(B)<<endl;
cout<<sizeof(C)<<endl;
return 0;
}
And the result for this program is as the following:
8
4
16
16
32
As i was saying that object of class A will have a VPTR (pointing to the VTABLE of A) and an int. The pointer will be 8 byte long and the int will be 4 byte long. Hence before compile the size is 12 bytes. But the compiler will add extra 4 bytes at the end of int a as padding bits to maintain the alignment of class A equal to the highest length of the data member of the class which is divisible by 2, that is vPtr (8 byte long). Hence after compilation, the A's objects size will be 12 + 4 = 16 bytes.
Similarly for class B's objects.
Now object of C will have two VPTRs (one for each class A & class B) and 3 ints (a,b,c). So normally the size of object of C should have been 8 + 8 + 3*4 = 28 bytes. But here is what happens because the compiler adds padding bytes. After the addition of the padding bytes, the size becomes 8 (VPTR A) + 4 (int a) + 4 (padding bytes) + 8 (VPTR B) + 4 (int b) + 4 (int c) = 32 bytes. So the total size of C will be 32 bytes.
Note:
Type this to see the memory dump on the screen using gcc compiler
g++ -fdump-class-hierarchy=stdout MemoryLayout.cpp
where MemoryLayout.cpp is the file containing the class hierarchy…
