Member Avatar for shanki himanshu 
struct abcd
 {
     char q;
     int w;
     //long int e;
 };

why size of this structure is 8 bytes and if i include long int e , size becomes 12 bytes?

Edited by shanki himanshu
  • 3 Contributors
  • 6 Replies
  • 128 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by Member #957352

Dani AI

Generated

Short answer: the compiler inserts padding so each member sits at an address the ABI requires. That both creates the internal gaps you saw and forces the whole struct size to be rounded up to the largest member alignment. In other words, the layout depends on each type's alignment requirement (which is ABI- and compiler-dependent) as well as the order of members.

How to reason about it quickly: start at offset 0 and place members in order. For each member, round the current offset up to the member’s alignment (align(x,a) = ((x + a - 1) / a) * a), place the member there, then add its size. After the last member round the total up to the struct alignment (the maximum alignment of any member). That predicts the padding and final sizeof without trial-and-error.

To check exactly what your compiler does, use sizeof and offsetof at runtime. For example:

#include <stdio.h>
#include <stddef.h>

struct S { int w; char q; };

int main(void) {
  printf("sizeof(struct S) = %zu\n", sizeof(struct S));
  printf("offsetof(w) = %zu\n", offsetof(struct S, w));
  printf("offsetof(q) = %zu\n", offsetof(struct S, q));
}

Practical tips: group fields by decreasing alignment (largest types first) to reduce internal padding; prefer fixed-width types (int32_t, int64_t) for predictable sizes across platforms; avoid __attribute__((packed)) or #pragma pack unless you really need a byte layout for I/O — packed structs can cause slower access or hardware faults on some CPUs. Also note that long size varies by platform (LP64 vs LLP64), so adding long int e will change the layout differently on Linux x86_64 versus Windows x64.

As pointed out, the gaps you observed are intentional; use offsetof/sizeof (and the ordering tricks above) to verify and reduce wasted space when it matters.

Recommended Answers

All 6 Replies

Member Avatar for deceptikon

Members of a structure may be aligned to certain byte boundaries to improve performance or if the platform simply doesn't allow an object of a certain type to begin at any byte. Also, and partially to facilitate alignment, there may be padding between members of a structure or at the end of the structure.

So unless you go out of your way to pack a structure (using non-portable methods), its size will likely be more than the sum of its members' sizes.

Edited by deceptikon
Member Avatar for shanki himanshu

how performance is increased?
are structure elements location in memory contiguous? if yes, in this case then there is free memory blocks after char variable as size is greater than individual sum? correct me if i am wrong.

Member Avatar for deceptikon

how performance is increased?

Values can be loaded into memory and registers more quickly when they're suitably aligned. Otherwise the system might have to calculate an offset from a native boundary to get to the correct address.

are structure elements location in memory contiguous?

Barring padding, yes.

if yes, in this case then there is free memory blocks after char variable as size is greater than individual sum?

In this case I'd wager that there are 3 bytes of padding after q so that w is properly aligned on a word boundary. So the structure looks like this in memory:

[q][?][?][?][w][w][w][w]
Member Avatar for shanki himanshu

does that means that order in which i write the structures elements matter to calculate the offset and hence size changes?
also 3 bytes are free here.. isnt it memory wastage though small?

Member Avatar for deceptikon

does that means that order in which i write the structures elements matter to calculate the offset and hence size changes?

Yes. My personal preference is to order members in a way that makes intuitive sense at a higher level than padding and alignment, but that's just a general guideline. I've been known to optimize the organization of my structures when the situation warranted it. ;)

also 3 bytes are free here.. isnt it memory wastage though small?

This is one of many places where you'll encounter the speed vs. space tradeoff. At the cost of a few bytes, the performance can be improved by a statistically significant amount.

Member Avatar for Member #957352

there is padding after each element of structures so as to fit it in a boundary which is neccessary for a computer. it is done because while reading data, it has to take the offset and then read, so to save this time , padding is done ;) thanks

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.