Hi
On 6 August 2011 20:20, SANDEEP CHUGH <[email protected]> wrote:
> padding wud be between int & char..(for ur last case)
>
> now u said if it starts at 4 , still the block will be 8 (size of double),
> that is 7 bytes to be padded..
>
> so double element of structure would be starting at 4 + char(1) + 7 byte
> padding ==12
>
> but 12 is not a multiple of 8..
>
the whole concept is about the alignment and word size.
If word size is 4( 32 bit m/c) then the memory allocation would start at a
multiple of 4 and if it is 8 , then the memory allocation would start at a
multiple of 8.
Moreover, the explaination I gave above hold for 64 bit architecture.
For 32 bit architecture a double is 8 bytes aligned but the word size is 4
bytes, so for a structure like this
struct a
{
double d;
int i;
}
the size would be 12 (on 32 bit) and 16 (on 64 bit)
> so there is a problem??
>
>
>
>
>
>
> On Sat, Aug 6, 2011 at 8:06 PM, siddharth srivastava
> <[email protected]>wrote:
>
>> 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.
>>
>
> --
> 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.
