Between Variable (a) and (b) is 4 bytes space but for (c) its different. There is approximately 6000 bytes space. What’s the point of this?
I’ve learnt that initialized variable is stored in .data section, uninitialized variables in .bss and pointers in heap. But here I am really confused. Why addresses in code one is contiguous with 12 bytes spaces. Why 12? If integer is 4 bytes! What is this extra 8 bytes?
And why uninitialized variable is close to a pointer variable that is supposed to be in heap section.
Why base address for variables inside main function is 0012FED4 but for second code its 00456014.
Please someone write me a line about this issue.
Thanks for any advance.
As you can see there is 12 bytes space between every address.
[...]
Why addresses in code one is contiguous with 12 bytes spaces. Why 12? If integer is 4 bytes! What is this extra 8 bytes?
You most probably did this test with a debug build. In this case, the extra bytes are guard bytes added to detect stray memory accesses. When I tested this with a release build, they all lined up neatly tight using four bytes each, though in a different sequence. (Tested with VC++ 2010.)
And why uninitialized variable is close to a pointer variable that is supposed to be in heap section.
The dynamically allocated (with new or malloc()) space the pointer points to is supposed to be located on the heap, not the pointer itself. In that respect the pointer is not any different from any other POD variable.
Why base address for variables inside main function is 0012FED4 but for second code its 00456014.
Non-static local variables, whether initialized or not, are located on the stack, which is not taken into account here (and, as pointed out, your assumption about the pointers is wrong):
I’ve learnt that initialized variable is stored in .data section, uninitialized variables in .bss and pointers in heap.
Thus it is natural for those addresses to be far apart, though not compelling.
The bottom line of all that is, though, that it's not our task to worry about those things, it's that of the folks who write the compilers and perhaps the standard libraries. Stuff like that is highly implementation-dependent and you can't safely make any assumptions about it.
thank you guys.you are amazing.please forgive me if i didnt reply quickly.its becouse i dont have internet in home and i have to come to coffeenet .
i have read your answers .it is so helpful.
and thank you again for your welcoming.
Bookmarks