Memory alignment "suggestions collection" of classes in C + +

Hello, everyone. Meet again. I'm Jun Quan.

1. For the memory occupation of classes in C + +, there is a point that is prone to errors. That is: when no member variable or virtual function is defined in a class, the memory occupation is as follows:

class MyClass
{ 
   
public:
	MyClass();
	~MyClass();
	//virtual void fun() {}; // 4

private:
	//int a; // 4
	//char b; // 1
	//double c; // 8
};

MyClass::MyClass()
{ 
   
}

MyClass::~MyClass()
{ 
   
}

int main()
{ 
   
	// test03
	std::cout << "size int :" << sizeof(int) << " size char:" << sizeof(char) << " size double:" << sizeof(double) << std::endl;
	std::cout << "size MyClass:" << sizeof(MyClass) << std::endl;
}

Ladies and gentlemen, what do you think the result will be?

Yes, the result is not 0 but 1. This class that does not define any member variables or virtual functions occupies a byte.

size int :4 size char:1  size double:8
size MyClass:1

So just why? Because the memory unit of an object without data members is not 0, c + + uses a memory unit to represent the existence of the instance object.

2. How many bytes are used as the alignment standard for the memory alignment of classes in C + +? Four? Eight? Or more? The code is as follows. Let's guess.

class MyClass
{ 
   
public:
	MyClass();
	~MyClass();
	//virtual void fun() {}; // 4

private:
	int a;      // 4
	char b;     // 1
	//double c; // 8
};

MyClass::MyClass()
{ 
   
}

MyClass::~MyClass()
{ 
   
}

int main()
{ 
   
	// test03
	std::cout << "size int :" << sizeof(int) << " size char:" << sizeof(char) << " size double:" << sizeof(double) << std::endl;
	std::cout << "size MyClass:" << sizeof(MyClass) << std::endl;
}

The output is as follows:

size int :4 size char:1  size double:8
size MyClass:8

4 bytes as alignment? Yes, in this case, 4 bytes are used as the alignment, but is it true that 4 bytes are used as the memory alignment standard? In fact, it's not. Let's take a look at the following code.

class MyClass
{ 
   
public:
	MyClass();
	~MyClass();
	//virtual void fun() {};

private:
	//int a; // 4
	char b;     // 1
	double c;    // 8
};

MyClass::MyClass()
{ 
   
}

MyClass::~MyClass()
{ 
   
}

int main()
{ 
   
	// test03
	std::cout << "size int :" << sizeof(int) << " size char:" << sizeof(char) << " size double:" << sizeof(double) << std::endl;
	std::cout << "size MyClass:" << sizeof(MyClass) << std::endl;
}

The output results are as follows:

size int :4 size char:1  size double:8
size MyClass:16

Now the memory alignment standard has become 8 bytes, which is not the case. The aligned bytes of classes in C + + are not a fixed number, but the type with the largest number of bytes occupied by member variables in the class is used as the alignment standard.

3. At the same time, there is a memory occupation type (virtual function table) that is very easy to ignore. Note that the class has virtual function pointer. Don't forget that the virtual function pointer still has 4 bytes. The code is as follows:

class MyClass
{ 
   
public:
	MyClass();
	~MyClass();
	virtual void fun() { 
   };

private:
	//int a; // 4
	//char b; // 1
	//double c; // 8
};

MyClass::MyClass()
{ 
   
}

MyClass::~MyClass()
{ 
   
}

int main()
{ 
   
	// test03
	std::cout << "size int :" << sizeof(int) << " size char:" << sizeof(char) << " size double:" << sizeof(double) << std::endl;
	std::cout << "size MyClass:" << sizeof(MyClass) << std::endl;
}

What will the output be? 4? Wrong, not 4, but 8

size int :4 size char:1  size double:8
size MyClass:8

Why 8 bytes? Because this is related to the first error prone point, because there is no member data defined in this class. c + + uses a memory unit to represent the existence of this instance object. This memory byte, because there is a virtual function table (4 bytes), after memory alignment, the memory occupied by this class is 8 instead of 4.

Publisher: full stack programmer, stack length, please indicate the source for Reprint: https://javaforall.cn/115091.html Original link: https://javaforall.cn

Added by davidcriniti on Tue, 08 Feb 2022 02:59:39 +0200