How do u define size of compiler...?

On 8/6/11, SANDEEP CHUGH <[email protected]> wrote:
> @ 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
> <[email protected]>wrote:
>
>>
>>
>> On 6 August 2011 21:50, siddharth srivastava <[email protected]> wrote:
>>
>>> 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
>>>
>> 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 <
>>>> [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
>>>
>>>
>>>
>>
>>
>> --
>> 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.
>
>

-- 
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.

Reply via email to