Memory allocation
-
Hi every one! Can any one explain me why is this happening struct SOME { char s0[1]; char s1[2]; char s2[1]; }; int main() { SOME *sm = new SOME; delete sm; return 0; } before allocation (with new) 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf } after allocation 0x00332e98 { s0=0x00332e98 " πΊ««««««««ξώξώ" s1=0x00332e99 "πΊ««««««««ξώξώ" s2=0x00332e9b "Ί««««««««ξώξώ" } after deallocation (with delete) 0x00332e98 <----- Is that a problem? { s0=0x00332e98 "" <----- s1=0x00332e99 "3" <----- s2=0x00332e9b "" <----- } thanks!
-
Hi every one! Can any one explain me why is this happening struct SOME { char s0[1]; char s1[2]; char s2[1]; }; int main() { SOME *sm = new SOME; delete sm; return 0; } before allocation (with new) 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf } after allocation 0x00332e98 { s0=0x00332e98 " πΊ««««««««ξώξώ" s1=0x00332e99 "πΊ««««««««ξώξώ" s2=0x00332e9b "Ί««««««««ξώξώ" } after deallocation (with delete) 0x00332e98 <----- Is that a problem? { s0=0x00332e98 "" <----- s1=0x00332e99 "3" <----- s2=0x00332e9b "" <----- } thanks!
I don't see a problem. What specifically are you asking?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
I don't see a problem. What specifically are you asking?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
first: in that below, why the memory addresses of s0, s1, s2 are different and has these values 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf } second: after deallocation the memory addresses are still assigned to s0, s1, s2 0x00332e98 { s0=0x00332e98 "" s1=0x00332e99 "3" is that a problem s2=0x00332e9b "" }
-
first: in that below, why the memory addresses of s0, s1, s2 are different and has these values 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf } second: after deallocation the memory addresses are still assigned to s0, s1, s2 0x00332e98 { s0=0x00332e98 "" s1=0x00332e99 "3" is that a problem s2=0x00332e9b "" }
Dennis L wrote:
in that below, why the memory addresses of s0, s1, s2 are different...
As opposed to all being the same?
Dennis L wrote:
after deallocation the memory addresses are still assigned to s0, s1, s2
And what would you expect them to be? All
deletedoes is tell the memory manager that address 0x00332e98 is available for use again."Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
Hi every one! Can any one explain me why is this happening struct SOME { char s0[1]; char s1[2]; char s2[1]; }; int main() { SOME *sm = new SOME; delete sm; return 0; } before allocation (with new) 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf } after allocation 0x00332e98 { s0=0x00332e98 " πΊ««««««««ξώξώ" s1=0x00332e99 "πΊ««««««««ξώξώ" s2=0x00332e9b "Ί««««««««ξώξώ" } after deallocation (with delete) 0x00332e98 <----- Is that a problem? { s0=0x00332e98 "" <----- s1=0x00332e99 "3" <----- s2=0x00332e9b "" <----- } thanks!
Dennis L wrote:
Is that a problem?
In short: no, unless you're trying to use it. The fact that you have released the memory you previously allocated does not make the pointer to point somewhere else. The memory should not be used after being deallocated since it may contain invalid data as you've instructed the memory manager that you don't need it any longer by deallocating it. This is why it's considered best practice to assign NULL to pointers you've deallocated to be able to test on the pointer to see if you can use the memory it points to.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Hi every one! Can any one explain me why is this happening struct SOME { char s0[1]; char s1[2]; char s2[1]; }; int main() { SOME *sm = new SOME; delete sm; return 0; } before allocation (with new) 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf } after allocation 0x00332e98 { s0=0x00332e98 " πΊ««««««««ξώξώ" s1=0x00332e99 "πΊ««««««««ξώξώ" s2=0x00332e9b "Ί««««««««ξώξώ" } after deallocation (with delete) 0x00332e98 <----- Is that a problem? { s0=0x00332e98 "" <----- s1=0x00332e99 "3" <----- s2=0x00332e9b "" <----- } thanks!
Dennis L wrote:
Can any one explain me why is this happening ... before allocation (with new) 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf }
It's for debugging purposes I think - this way it's easier to detect if you're using your data before you've initialized it.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition. Blaise Pascal
-
Dennis L wrote:
in that below, why the memory addresses of s0, s1, s2 are different...
As opposed to all being the same?
Dennis L wrote:
after deallocation the memory addresses are still assigned to s0, s1, s2
And what would you expect them to be? All
deletedoes is tell the memory manager that address 0x00332e98 is available for use again."Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
first I have read that all local variables that are not initialized explicitly are being intialiazed to 0xcccccccc with the Microsoft compilers. The first OK but the other two? second what happens with this address if the program exits or is this void func1() { SOME *sm = new SOME; delete sm; } void func2() { func1(); // What happents here? }
-
first I have read that all local variables that are not initialized explicitly are being intialiazed to 0xcccccccc with the Microsoft compilers. The first OK but the other two? second what happens with this address if the program exits or is this void func1() { SOME *sm = new SOME; delete sm; } void func2() { func1(); // What happents here? }
Dennis L wrote:
what happens with this address if the program exits
It is reclaimed by the memory manager.
Dennis L wrote:
// What happents here?
Nothing.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
Dennis L wrote:
what happens with this address if the program exits
It is reclaimed by the memory manager.
Dennis L wrote:
// What happents here?
Nothing.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
-
Hi every one! Can any one explain me why is this happening struct SOME { char s0[1]; char s1[2]; char s2[1]; }; int main() { SOME *sm = new SOME; delete sm; return 0; } before allocation (with new) 0xcccccccc { s0=0xcccccccc s1=0xcccccccd s2=0xcccccccf } after allocation 0x00332e98 { s0=0x00332e98 " πΊ««««««««ξώξώ" s1=0x00332e99 "πΊ««««««««ξώξώ" s2=0x00332e9b "Ί««««««««ξώξώ" } after deallocation (with delete) 0x00332e98 <----- Is that a problem? { s0=0x00332e98 "" <----- s1=0x00332e99 "3" <----- s2=0x00332e9b "" <----- } thanks!
Well, what's being missed is that s0,s1 and s2 are char Arrays of 1,2 and 1 byte respectively, and NOT poiners! Why are they being displayed as DWORD. What byte packing is used. Unless if you have a constructor SOME(), in which you specifically initialise the structure, you should not rely on the content of the structure because it is unpredictable. The DEBUG version of the compiler tries to pad uninitialised and deleted structures with garbage in an attempt to make your code blow if you by mistake forget to initialise, or attempt to refer to de-allocated data. The Release version is by no means as friendly, in that it does none of these things. If your code works while referring to data outside their validity scope, you create a timebomb which at some time in the future will cause unpredictable and mysterious crashes. I note that you read the structure after deallocation, This mere read could lead to an invalid memory access crash. (ever tried to read a NULL pointer?) Regards, :)
Bram van Kampen