struct size

[hypheni]

though this is a simple qus im a bit confused.

how many bytes are allocated for this structure?

struct data
{
int i;
char c;
int j;
};

What if you use #pragma pack?.

And please explain me #pragma pack, i didnt understood it from msdn.

is it calculated as (int = 4bytes + char = 1byte + int = 4bytes) ?

[Lindley]

The compiler is free to allocate as many bytes for a struct as it feels appropriate. If you use pragma pack then it should generate a size like you expect, but I'm not sure if that's guaranteed.

Basically, computers access memory more efficiently on addresses which are multiples of 4 or 16. Some types in fact *require* this alignment. Depending on compiler settings, therefore, the fields of the struct may not be exactly adjacent in memory; padding for alignment may be inserted by the compiler. Praga pack instructs the compiler specifically *not* to do this.

[hypheni]

means normal declaration of

int i;

and

struct a{
int i;
};

differs in sizes ?

[Lindley]

In that case probably not, but I don't know the standard well enough to say whether there are any guarantees.

[ninja9578]

Try this

struct data{
   int i __attribute__ ((packed));
   char c;
   int j __attribute__ ((packed));
};

It's GNU specific, but then again, so is #pragma pack

[hypheni]

I just want to know how much bytes this struct will take, leave the pragma pack..

struct data
{
int i;
char c;
int j;
};

[Martin O]

I just want to know how much bytes this struct will take

Then use sizeof

[hypheni]

yes sizeof (data) returns 12bytes. But if I count it individually it should :

4bytes + 1byte + 4bytes = 9bytes

[Lindley]

That's what I've been saying. The compiler is adding a few bytes to ensure the third field is on a 4-byte boundary for efficient access.

[hypheni]

So that means these extra bytes depending on compiler and for safe handling of memory ?

[Lindley]

So that means these extra bytes depending on compiler and for safe handling of memory ?

I'm not quite sure what you're asking here. The choice of struct padding is dependent upon the compiler and the compile options and may change if you build in a different environment.

[ninja9578]

Te reason it does that is because most computers perform much better if your memory is WORD aligned. Usually a WORD is 4 bytes, so your compiler will expand and ever rearrange your struct to make that happen. You can stop the compiler from doing any rearranging by wrapping it in extern "C"{}, but even that will cause padding for alignment.

[Paul McKenzie]

yes sizeof (data) returns 12bytes. But if I count it individually it should :

But it is not "individual" -- it is a struct, and a struct is one item. So to get the sizeof() a struct, you get sizeof(struct).

Regards,

Paul McKenzie

[hypheni]

Yes that I posted earlier that if I use sizeof(struct) is gives 12. but considering the struct contents value its not being 12, thats why asked.

one qus. does structure really defines its memory allocation apart from its content ?.

[monarch_dodra]

Te reason it does that is because most computers perform much better if your memory is WORD aligned. Usually a WORD is 4 bytes, so your compiler will expand and ever rearrange your struct to make that happen. You can stop the compiler from doing any rearranging by wrapping it in extern "C"{}, but even that will cause padding for alignment.

This claim sparked my curiosity, as I was taught that elements in structs can't be re-arranged, ever, in C or C++. So I investigated a bit. I found these two interesting answers:

http://stackoverflow.com/questions/9.../916691#916691
http://stackoverflow.com/questions/1.../118177#118177

Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (11.1)

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared.

Long story short, it can't.

So yeah, that means the order of declaration can make a difference in the final struct size.

Unless you are on a very space-bound system though, I wouldn't worry too much about it, and declare elements in an order that makes sense to a human operator. And respect things like add new elements at the bottom, this makes it easier for change tacking.