int* pi;
{
int ar[1000000];
int a =3,b=4;
ar[3]=a*b
pi=ar;
}//ar is destroyed
int ar2[]={5,6,7,8,9};
char* f="zcxzsdaaaaaaaaa";
std::cout<<pi[3]<<std::endl;// prints 12
I have 2 questions:
I heard that the stack contains only pointers to data. And if so where is the data stored? For example char* a="bbbb"; a - placed on stack, "bbbb" - somewhere else. Where?
Doesn't the above code working correctly mean a memory leak of 1000000 bytes? Variable ar is destroyed but the data that it pointed to still exists. And we can't use delete here since ar is not dynamically allocated.
I heard that stack contain only pointers to data
You heard wrong. The stack contains the actual data. However, if that data is a pointer then that is what is stored.
And if so where is data stored? For example char* a="bbbb"; a - placed on stack, "bbbb" - somewhere else. Where?
Yes, a (the pointer) is stored on the stack. The actual string "bbbb" is stored in a fixed part of the executable.
Doesnt code above working correctly mean memory leak of 1000000 bytes? Variable ar is destroyed but data that it pointed to still exists. And we cant use delete here since ar is not dynamically allocated.
No, there is a difference between arrays and pointers to arrays. ar (the whole 1000000 bytes) will be stored on the stack. This is different from char const* ar = "... 1000000 chars ...";. As ar is on the stack, it will be "freed" automatically.
char const* a = "abcde"; // a is on the stack, pointing to "abcde" somewhere else.
char const b[6] = "abcde"; // *all* of b is on the stack, all 6 bytes
The problem in your code is that pi is pointing to something on the stack which is no longer there. It may well be there when you run the code because "freeing" data on the stack doesn't do anything to the data in non-debug builds. It's not a memory leak, you just have an invalid pointer.
Final note: Although essentially all modern computer architectures make use of a call stack, the C++ standard makes no mention of it. Note that people will often say that a variable is "on the stack", but it may actually just live in a register. For example, if you compiled your code, the variable pi probably wouldn't ever touch the stack, it would likely just stay in a register for the duration of the function because going to the stack is relatively expensive (compared to registers).
ar is also located "on stack". You technically can access it because the memory is still mapped into address space (stack is usually mapped as a whole) and see the same data as previously stored because data happens to not have been overwritten.
Doing so is undefined behavior - you can read overwritten data or your program may crash or anything else may happen including perceived normal operation. Don't rely on this behavior and don't try this in real code (trying this for educational purposes and asking on SO is okay).
There's no memory leak here - stack memory is automatically reclaimed when the function exits.
1) All variables are on the stack. You don't allocate memory yourself.
2) There is no memory leak. The whole variable is on the stack and is destroyed when the scope of the variable is exited. You're not allocating anything with new.
It doesnt seem the confusion of memory leakage is really addressed. In C++ to allocate memory yourself you use the new keyword or malloc and this is when memory leakage is a concern. The lanaguage is designed that all local variables memory space are reclaimed once it becomes out of scope. As everyone pointed the ar is in the local scope of pi{} so once that is exited, those memory locations could be reused or easily overwritten,so if you would have printed the results of pi later in the code with manipulating the stack like you were in that {} scope than pi could be a different value
