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