@ sid : can u please elaborate considering these parameters
1 size of compiler
2 size of os and
3 size of processor
please explain for any case, considering these three parameters and tell me
how these parameters do affect..
ty
On Sat, Aug 6, 2011 at 9:53 PM, siddharth srivastava <akssps...@gmail.com>wrote:
>
>
> 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.
>
--
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.
