can you please find out the amount of space consumed

[rohitbasu77]

Thanks..... Realy healpfull..

No it doesn't, your implementation of C may provide a #pragma pack preprocessor directive but this is NOT standard C and many compilers do not provide this or any way to change structure alignment, you have to live with what ever it does. If your compiler has a #pragma pack and you use it then you will implicitly introduce an portability issue if the hardware of your project ever changes.

I am fully aware of the memory constraints that occur on smaller platforms (having programmed on a PIC with <4k RAM for the past year or so) the sizeof operator will give you the sizeof the type, if that type is a structure then it will include the padding (otherwise pointer arithmetic would not work properly).

Take this code for instance

[code=c]
struct MyStruct {
int i;
char c;
};

struct MyStruct mystruct;
int sms = sizeof mystruct;
int si = sizeof mystruct.i;
int sc = sizeof mystruct.c;
[/code]Assuming that the system has 4 byte (32 bit ints) and that it uses 4 byte alignment then once this runs

sms = 8;
si = 4;
sc = 1;

You can always find out how much wasted space there is in a structure on a given compiler/platform by comparing the sizeof the struct with the size of it's components, in this case 3 bytes (8 - (4+1)).

However it you use the rules I gave previously then wasted space will be minimised (typically 0-3 bytes per structure) on most platforms.

If you can not afford that wasted space don't use structures, although this will make the code more complex so you need to give the problem some careful thought before going down this route.

[rohitbasu77]

But if i change it to:

struct MyStruct {
char c;
int i;
};

what will be the result... will it be same as previous one...

No it doesn't, your implementation of C may provide a #pragma pack preprocessor directive but this is NOT standard C and many compilers do not provide this or any way to change structure alignment, you have to live with what ever it does. If your compiler has a #pragma pack and you use it then you will implicitly introduce an portability issue if the hardware of your project ever changes.

I am fully aware of the memory constraints that occur on smaller platforms (having programmed on a PIC with <4k RAM for the past year or so) the sizeof operator will give you the sizeof the type, if that type is a structure then it will include the padding (otherwise pointer arithmetic would not work properly).

Take this code for instance

[code=c]
struct MyStruct {
int i;
char c;
};

struct MyStruct mystruct;
int sms = sizeof mystruct;
int si = sizeof mystruct.i;
int sc = sizeof mystruct.c;
[/code]Assuming that the system has 4 byte (32 bit ints) and that it uses 4 byte alignment then once this runs

sms = 8;
si = 4;
sc = 1;

You can always find out how much wasted space there is in a structure on a given compiler/platform by comparing the sizeof the struct with the size of it's components, in this case 3 bytes (8 - (4+1)).

However it you use the rules I gave previously then wasted space will be minimised (typically 0-3 bytes per structure) on most platforms.

If you can not afford that wasted space don't use structures, although this will make the code more complex so you need to give the problem some careful thought before going down this route.

[Banfa]

But if i change it to:

struct MyStruct {
char c;
int i;
};

what will be the result... will it be same as previous one...

In all likelihood in this simple case yes.

The thing to avoid (as I mentioned) is mixing your types within the structure so this

struct MyStruct1 {
    char c1;
    long l1;
    short s1;
    long l2;
    char c2;
};

is likely to be bigger than

struct MyStruct2 {
    long l1;
    long l2;
    short s1;
    char c1;
    char c2;
};

unless your system uses 1 byte alignment. In a system where chars are byte aligned (actually the standard guarantees this), shorts are 2 byte aligned and longs are 4 byte align

sizeof(struct MyStruct1) == 20 bytes
sizeof(struct MyStruct2) == 12 bytes

In general ordering your structure members by size is likely to give you the most efficent packing for most common sets of packing rules.

[MACKTEK]

In a simple test, I used
{
struct MyStruct {
int i;
char c1;
char c2;
char c3;
char c4;
char c5;
int ii;
};
I commented out c2 thru c5 to see the development of memory use.
The struct used 4 bytes for each int.
For the First char it used 4 bytes, and did not use any more until the 5th char.

So it seems it is allocating 4 bytes whether you want them or not.
But again, that is on my system running VC++ 2005

Also
{
struct MyStruct {
int i1; // used 4 bytes
char c1; // uses 1 byte but allocates 4
short s1; // uses 2 bytes but allocates 4
char c2; // uses 1 byte
//char c3;
// short s2;
//char c4;
int i2;
};

Total Used 16 bytes. 8 for the 2 int, 4 for the first char, 4 for the first short.

[Banfa]

This is normal, it is fairly normal for a 32bit processor to need a 32bit number on a 32bit boundary in memory to access it efficiently (i.e. using a single instruction). The standard guarantees that you can access every single byte in memory sequentially so in a structure a char followed by a int (on a 32 bit system) requires that the structure is padded out so that the int appears at the 32 bit boundary. When you put in an extra char it can just use a byte from the padding because it can access each individual byte.

Additionally the entire structure must be correctly aligned (to enable you to have an array of them and still access them efficiently) so padding can also appear at the end of the structure to bring it size up to a multiple of it's minimum alignment (try repeating your experiment with int ii and you will see what I mean).

This is why I say order members in the structure largest to smallest because you are very unlikely to get any padding mid structure only a few bytes at the end.

The situation can get even more complex when you have structures nested in structures but it all becomes heavily platform dependent.

I have worked on platforms where chars appear at any location, shorts had to appear at 2 byte boundaries and longs had to appear at 4 byte boundaries. Structures however could appear at the boundary of the largest item they contained 1, 2 or 4 bytes for char, short or long.

I have also worked with hardware where the packing was fairly straight forward but the where attached peripherals that required there buffers to be 64bit aligned.

[rohitbasu77]

yes, its true that when using such complicated structure, u must use Banfa's algorithim..... .
Realy the discussion help me a lot....
Thanks Banfa....