On 6 August 2011 21:50, siddharth srivastava <akssps...@gmail.com> wrote:
> Hi
>
> On 6 August 2011 20:20, SANDEEP CHUGH <sandeep.aa...@gmail.com> 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
>
just a correction:
on gcc, double is 4 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)
>
the result are for linux(gcc) system
>
>
>> so there is a problem??
>>
>>
>>
>>
>>
>>
>> On Sat, Aug 6, 2011 at 8:06 PM, siddharth srivastava <akssps...@gmail.com
>> > 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 <
>>>> akssps...@gmail.com> wrote:
>>>>
>>>>> Hi Sandeep
>>>>>
>>>>> On 6 August 2011 19:16, SANDEEP CHUGH <sandeep.aa...@gmail.com> 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 algogeeks@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> algogeeks+unsubscr...@googlegroups.com.
>>>>>> 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 algogeeks@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> algogeeks+unsubscr...@googlegroups.com.
>>>>> 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 algogeeks@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> algogeeks+unsubscr...@googlegroups.com.
>>>> 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 algogeeks@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> algogeeks+unsubscr...@googlegroups.com.
>>> 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 algogeeks@googlegroups.com.
>> To unsubscribe from this group, send email to
>> algogeeks+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/algogeeks?hl=en.
>>
>
>
>
> --
> Regards
> Siddharth Srivastava
>
>
>
--
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 algogeeks@googlegroups.com.
To unsubscribe from this group, send email to
algogeeks+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/algogeeks?hl=en.
