>
> but if the reference is not 0 .. if it wud have been 4 then for tht case
> tell me do we really need that 7 bytes??
>
yes, because in any case the block would be of 8 bytes only
so even if you start at 4, you would have only 7 bytes left in that location
for the next variable(which in this case is a double of 8 bytes, so the
allocation would start at the 8th byte from the first location)
Look at the following stack: X represents occupied memory, - represents the
memory to be padded (in bytes)
X - - - - - - -
XXXXXXXX
XXXX - - - -
So, first char occupies 1 byte, then there are only 7 bytes left at that
index, which are not enough for a double to be stored (got my point)
Moreover, if you had
struct a{
char c;
int i;
double d;
}
then the size would have been 16
as after allocating a char, there was enough space for an int to be stored.
(just not sure if padding would be after int or between int and char)
>
> and yeah it is dependent on compiler size..
> if u compile this snippet
>
> struct demo
> {
> char c;
> double d;
> int s;
>
>> }
>
>
> in turbo c , its giving 11,, that means compiler nt doing padding at all in
> turbo c..
>
> On Sat, Aug 6, 2011 at 7:50 PM, siddharth srivastava
> <[email protected]>wrote:
>
>> Hi Sandeep
>>
>> On 6 August 2011 19:16, SANDEEP CHUGH <[email protected]> wrote:
>>
>>> take this case
>>>
>>> struct demo
>>> {
>>> char c;
>>> double d;
>>> int s;
>>>
>>>> }
>>>
>>>
>>> what wud be the size??
>>>
>>>
>>> solution is 24 according to following:-->
>>>
>>> char (1) + 7 byte padding +double(8)+int(4)+ 4 byte padding
>>>
>>>
>>> suppose address starts at 4..
>>>
>>> i just wanna ask .. why there is 7 byte padding.. because just after 3
>>> bytes padding after char we are getting address that is multiple of 8(size
>>> of largest)..
>>>
>>
>>
>> after 3 bytes of padding i.e. the 4th byte(if reference is 0), is not a
>> multiple of 8.
>> Moreover, try understanding with this example:
>> visualize a stack of memory with each location having the size of the
>> largest sized variable in the structure.
>> So in your case, each stack element is ought to be 8 bytes (due to double)
>> Now, when first character is allocated, we have only 7 bytes left at that
>> location in the stack, hence double has to be allocated in the next
>> location.i.e. 2nd stack element and 8th byte (again reference 0)
>>
>> So total size is ought to be occupied is 24 in this case
>>
>>
>> say if you had this declaration:
>> struct a
>> {
>> char a;
>> double d;
>> int c;
>> int e;
>> }
>>
>> then too size would have been 24 as after allocation of int c, we still
>> have 4 bytes in the same location which are then occupied by e (and were
>> padded in previous case)
>>
>> Let me know, if I am not clear.
>>
>> @All
>> Is it really architecture dependent (32 bit or 64 bit) ?
>>
>>
>>
>>>
>>> can u please tell me??
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Algorithm Geeks" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/algogeeks?hl=en.
>>>
>>
>>
>>
>> --
>> Regards
>> Siddharth Srivastava
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Algorithm Geeks" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/algogeeks?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Algorithm Geeks" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/algogeeks?hl=en.
>
--
Regards
Siddharth Srivastava
--
You received this message because you are subscribed to the Google Groups
"Algorithm Geeks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/algogeeks?hl=en.
