Printable View
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) ?
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.
means normal declaration of
int i;
and
struct a{
int i;
};
differs in sizes ?
In that case probably not, but I don't know the standard well enough to say whether there are any guarantees.
Try this
It's GNU specific, but then again, so is #pragma packCode:struct data{
int i __attribute__ ((packed));
char c;
int j __attribute__ ((packed));
};
I just want to know how much bytes this struct will take, leave the pragma pack..
struct data
{
int i;
char c;
int j;
};
Then use sizeofQuote:
Originally Posted by hypheni
yes sizeof (data) returns 12bytes. But if I count it individually it should :
4bytes + 1byte + 4bytes = 9bytes
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.
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.Quote:
Originally Posted by hypheni
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.
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).Quote:
Originally Posted by hypheni
Regards,
Paul McKenzie
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 ?.
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:Quote:
Originally Posted by ninja9578
http://stackoverflow.com/questions/9.../916691#916691
http://stackoverflow.com/questions/1.../118177#118177
Quote:
Originally Posted by C++ Section 9.2.12
Long story short, it can't.Quote:
Originally Posted by C99 Section 6.7.2.1
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.
A structs contents is not only what you see visibly -- that's the point. The contents of the struct include padding bytes which you can't see or predict by just looking at a struct declaration.Quote:
Originally Posted by hypheni
Regards,
Paul McKenzie
My mistake, I thought the compiler would shift items to word align them in C++ :/
Thanks Paul. You cleared my doubt. But is there any trick to guess struct size.
sizeof() as been suggested many times.
You can use this rule of thumb though. Take the number of bytes you expect it to be, and round up to the next multiple of four. That's usually a pretty good guess, but it's only a guess. No promises.
You should never ever require the size of it (one exception I can think of,) because programmatically, you will use sizeof() and things like array indexing and offsets are calculated automatically (and at compile time of course)
Yes if I need to know this programmatically then sizeof is okay.
but if this qus is asked me in some written exam ?. actually the main posted qus is taken from some interview qus series.
The correct answer on a written exam would be to state that the struct size is dependent on compiler choice and compile options. If you wish you can state one possible size by rounding every field's size up to the nearest multiple of 4 and then adding, but be clear that's just a possibility, not a certain size.Quote:
Originally Posted by hypheni
If the question asks about pragma pack, then you can specify an exact size by using the alignment rules laid out here:
http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx
I don't think this is correct.Quote:
Originally Posted by Lindley
Should be 4 bytes on most platforms (is on OSX with GCC.) You actually want to add them all up first, then round. Not sure if you just mistyped or not, but thought I would clear it up for the OP. But again, this is a guess at the size.Code:struct foo {
short i;
short j;
};
The real rules are more complicated than what either of us suggested, but both will serve as "reasonable guesses" if you're trying to predict such things without a compiler in front of you.Quote:
Originally Posted by ninja9578
I imagine when getting into unions or bit fields the rules start getting really weird.