Why padding in structures is required? [duplicate] - c++

This question already has answers here:
Why isn't sizeof for a struct equal to the sum of sizeof of each member?
(13 answers)
Structure padding and packing
(11 answers)
Closed 7 years ago.
We know that the correct order of declaring variables in structures changes the size of a structure also because of padding. I have seen the reference here.
Suppose a structure is:
struct s {
char b; //1 for char
char c; //1 for char + 2 for padding
int a; //4 for int
}my_struct;
So the size of the my_struct is 8, but without padding it could be 6 which is less than 8.
So my question is: Why padding is done in structures? What is the necessity of this concept?
Because without padding the structure is of lesser size. My question is not related to when padding take place, it is more concerned about the concept of padding.

Many computer architectures have optimized memory access in an alignment different than 1 byte (usually, 1 word = 4 bytes). Aligned accesses is generally faster than unaligned ones (and sometimes, it is impossible to access unaligned data). For this reason, compilers pack the struct members in an optimally aligned fashion. In your example, it looks like the alignment is of size 2 bytes, thus b is at offset 0, c is at offset 2 and a is at offset 4, totaling 8 bytes (assuming a is 4 bytes long). Or, according to the inline comments, in your example, it looks like the optimal alignment is equal to the data size. Thus, b and c are adjacent because the size is 1 and so is the alignment, but a is 4 bytes long, and hence needs a 4-byte alignment.
At the bottom line - this is all very architecture dependent.

Related

Why the sequence of variable matter in memory allocaton in c++? [duplicate]

Someone explain me how does the order of the member declaration inside a class determines the size of that class.
For Example :
class temp
{
public:
int i;
short s;
char c;
};
The size of above class is 8 bytes.
But when the order of the member declaration is changed as below
class temp
{
public:
char c;
int i;
short s;
};
then the size of class is 12 bytes.
How?
The reason behind above behavior is data structure alignment and padding. Basically if you are creating a 4 byte variable e.g. int, it will be aligned to a four byte boundary i.e. it will start from an address in memory, which is multiple of 4. Same applies to other data types. 2 byte short should start from even memory address and so on.
Hence if you have a 1 byte character declared before the int (assume 4 byte here), there will be 3 free bytes left in between. The common term used for them is 'padded'.
Data structure alignment
Another good pictorial explanation
Reason for alignment
Padding allows faster memory access i.e. for cpu, accessing memory areas that are aligned is faster e.g. reading a 4 byte aligned integer might take a single read call where as if an integer is located at a non aligned address range (say address 0x0002 - 0x0006), then it would take two memory reads to get this integer.
One way to force compiler to avoid alignment is (specific to gcc/g++) to use keyword 'packed' with the structure attribute. packed keyword Also the link specifies how to enforce alignment by a specific boundary of your choice (2, 4, 8 etc.) using the aligned keyword.
Best practice
It is always a good idea to structure your class/struct in a way that variables are already aligned with minimum padding. This reduces the size of the class overall plus it reduces the amount of work done by the compiler i.e. no rearrangement of structure. Also one should always access member variables by their names in the code, rather than trying to read a specific byte from structure assuming a value would be located at that byte.
Another useful SO question on performance advantage of alignment
For the sake of completion, following would still have a size of 8 bytes in your scenario (32 bit machine), but it won't get any better since full 8 bytes are now occupied, and there is no padding.
class temp
{
public:
int i;
short s;
char c;
char c2;
};
class temp
{
public:
int i; //size 4 alignment 4
short s; //size 2 alignment 2
char c; //size 1 alignment 1
}; //Size 8 alignment max(4,2,1)=4
temp[i[0-4];s[4-2];c[6-7]]] -> 8
Padding in (7-8)
class temp
{
public:
char c; //size 1 alignment 1
int i; //size 4 alignment 4
short s; //size 2 alignment 2
};//Size 12 alignment max(4,2,1)=4
temp[c[0-1];i[4-8];s[8-10]]] -> 12
Padding in (1-4) and (10-12)

Why the size of my Person is 10 bytes, and not 16 ? [duplicate]

Someone explain me how does the order of the member declaration inside a class determines the size of that class.
For Example :
class temp
{
public:
int i;
short s;
char c;
};
The size of above class is 8 bytes.
But when the order of the member declaration is changed as below
class temp
{
public:
char c;
int i;
short s;
};
then the size of class is 12 bytes.
How?
The reason behind above behavior is data structure alignment and padding. Basically if you are creating a 4 byte variable e.g. int, it will be aligned to a four byte boundary i.e. it will start from an address in memory, which is multiple of 4. Same applies to other data types. 2 byte short should start from even memory address and so on.
Hence if you have a 1 byte character declared before the int (assume 4 byte here), there will be 3 free bytes left in between. The common term used for them is 'padded'.
Data structure alignment
Another good pictorial explanation
Reason for alignment
Padding allows faster memory access i.e. for cpu, accessing memory areas that are aligned is faster e.g. reading a 4 byte aligned integer might take a single read call where as if an integer is located at a non aligned address range (say address 0x0002 - 0x0006), then it would take two memory reads to get this integer.
One way to force compiler to avoid alignment is (specific to gcc/g++) to use keyword 'packed' with the structure attribute. packed keyword Also the link specifies how to enforce alignment by a specific boundary of your choice (2, 4, 8 etc.) using the aligned keyword.
Best practice
It is always a good idea to structure your class/struct in a way that variables are already aligned with minimum padding. This reduces the size of the class overall plus it reduces the amount of work done by the compiler i.e. no rearrangement of structure. Also one should always access member variables by their names in the code, rather than trying to read a specific byte from structure assuming a value would be located at that byte.
Another useful SO question on performance advantage of alignment
For the sake of completion, following would still have a size of 8 bytes in your scenario (32 bit machine), but it won't get any better since full 8 bytes are now occupied, and there is no padding.
class temp
{
public:
int i;
short s;
char c;
char c2;
};
class temp
{
public:
int i; //size 4 alignment 4
short s; //size 2 alignment 2
char c; //size 1 alignment 1
}; //Size 8 alignment max(4,2,1)=4
temp[i[0-4];s[4-2];c[6-7]]] -> 8
Padding in (7-8)
class temp
{
public:
char c; //size 1 alignment 1
int i; //size 4 alignment 4
short s; //size 2 alignment 2
};//Size 12 alignment max(4,2,1)=4
temp[c[0-1];i[4-8];s[8-10]]] -> 12
Padding in (1-4) and (10-12)

Size of struct is more than expected [duplicate]

This question already has answers here:
Why isn't sizeof for a struct equal to the sum of sizeof of each member?
(13 answers)
Closed 7 years ago.
I already read this question: struct padding in c++ and this one Why isn't sizeof for a struct equal to the sum of sizeof of each member?
and I know this isn't standardized but still I believe it's a legit question.
Why is the size of this struct 16 on a x64 system?
struct foo { char* b; char a;};
The effective size would be 8 + 1 = 9, but I know there's padding involved. Anyway I thought a would only be padded to reach the size of an int, i.e. with other 3 bytes giving a total of 12 bytes.
Is there any reason why the specific compiler (gcc) thought it should have 16 bytes as a size?
Wild guess: is it possible that the biggest type (e.g. double or in this case x64 pointer) will dictate the padding to use?
Likely the compiler is aligning the struct on an 8-byte word boundary to improve access speed. A struct size of 9 is probably going to slow down the CPU quite a bit with unaligned accesses (plus the stack pointer should never be on an odd address). A size of 12 (3 padding bytes), would work, but some operations, like the FPU operations, prefer an alignment of 8 or 16 bytes.
It is because of memory alignment. By default memory is not aligned on one bye order and this happens. Memory is allocated on 4-byte chunks on 32bit systems.
You can change this behavior by setting __attribute__((packed, aligned(x))) when you define your structure. By this memory is allocated on x-byte chunks.

Why does sizeof show 4 bytes for a char? [duplicate]

This question already has answers here:
Why isn't sizeof for a struct equal to the sum of sizeof of each member?
(13 answers)
Why does a struct consisting of a char, short, and char (in that order), when compiled in C++ with 4-byte packing enabled, come to a 6-byte struct?
(3 answers)
Closed 9 years ago.
So I am currently a student and am having a programming couse.
Today we had about the use of sizeof in different classes(if it had 1 int or 2 int´s and so on)
One part of the example I found weird was this:
class TwoIntAndACharClass
{
public:
int x_;
int y_;
char z_;
};
and the part to test it
TwoIntAndACharClass o3b;
cout << "Sizeof TwoIntAndACharClass = " << sizeof(o3b) << "\n";
So in the program i could see a class with 1 char took 1 byte. So when I saw this I thought I would see 9 bytes and not 12
So first I thought that it was weird but after some time I came to the conclusion that it might save some kind of blocks of 4 bytes.
To be 100% sure that this was true I then tried adding a new variable into the class(a double variable of 8 bytes) and the total size increased from 12 bytes to now 24 bytes. That ment that the char now had to be 8 bytes long so my last theory failed.
My last theory was that it would take the biggest already declared variable and use the size of that for the char variable _z , as this worked with both long long int(8 bytes) and a double(also 8 bytes)
So my question is, is my last theory true - or is it something different making the char take more memory then needed? (my teacher did say that each compiler could handle this differently but I have tried it on microsoft visual studio and a friend tried it on another compiler with the same results, but is that really true, is it the way the compiler handle this?)
Sorry for my poor english.
sizeof gives you the size of the struct, not the sum of the sizes of its members. Due to alignment requirements (ints generally like to be aligned on natural boundaries; 4 bytes on most platforms), the compiler will pad the struct to 12 bytes, so that when you have multiple instances of the struct adjacent to each other (e.g. in an array), they stay correctly aligned.
Most compilers have some custom extension to control padding, e.g. #pragma pack in Microsoft's compiler.

Why does the size of a class depends on the order of the member declaration? and How?

Someone explain me how does the order of the member declaration inside a class determines the size of that class.
For Example :
class temp
{
public:
int i;
short s;
char c;
};
The size of above class is 8 bytes.
But when the order of the member declaration is changed as below
class temp
{
public:
char c;
int i;
short s;
};
then the size of class is 12 bytes.
How?
The reason behind above behavior is data structure alignment and padding. Basically if you are creating a 4 byte variable e.g. int, it will be aligned to a four byte boundary i.e. it will start from an address in memory, which is multiple of 4. Same applies to other data types. 2 byte short should start from even memory address and so on.
Hence if you have a 1 byte character declared before the int (assume 4 byte here), there will be 3 free bytes left in between. The common term used for them is 'padded'.
Data structure alignment
Another good pictorial explanation
Reason for alignment
Padding allows faster memory access i.e. for cpu, accessing memory areas that are aligned is faster e.g. reading a 4 byte aligned integer might take a single read call where as if an integer is located at a non aligned address range (say address 0x0002 - 0x0006), then it would take two memory reads to get this integer.
One way to force compiler to avoid alignment is (specific to gcc/g++) to use keyword 'packed' with the structure attribute. packed keyword Also the link specifies how to enforce alignment by a specific boundary of your choice (2, 4, 8 etc.) using the aligned keyword.
Best practice
It is always a good idea to structure your class/struct in a way that variables are already aligned with minimum padding. This reduces the size of the class overall plus it reduces the amount of work done by the compiler i.e. no rearrangement of structure. Also one should always access member variables by their names in the code, rather than trying to read a specific byte from structure assuming a value would be located at that byte.
Another useful SO question on performance advantage of alignment
For the sake of completion, following would still have a size of 8 bytes in your scenario (32 bit machine), but it won't get any better since full 8 bytes are now occupied, and there is no padding.
class temp
{
public:
int i;
short s;
char c;
char c2;
};
class temp
{
public:
int i; //size 4 alignment 4
short s; //size 2 alignment 2
char c; //size 1 alignment 1
}; //Size 8 alignment max(4,2,1)=4
temp[i[0-4];s[4-2];c[6-7]]] -> 8
Padding in (7-8)
class temp
{
public:
char c; //size 1 alignment 1
int i; //size 4 alignment 4
short s; //size 2 alignment 2
};//Size 12 alignment max(4,2,1)=4
temp[c[0-1];i[4-8];s[8-10]]] -> 12
Padding in (1-4) and (10-12)