Click here to Skip to main content
14,775,690 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:

Thanks in advance.
I am using visual studio 2008 and having a small problem. I am a beginner in C++. Please help me out:

Problem: In the following code I am creating an array of 10 elements. As per my understanding this array will be allocated on the stack memory of function.
Whenever I call this function stack will be formed and deleted after execution of it.
In this way "*arr" should give run time error or memory exception because stack would have deleted by then. But still I am not getting any error why?

int* ArrayCreate(void)
    int arr[10] = {1,2,3,4,5,6};
    return arr;

int main()
int* arr = ArrayCreate();
int i = *arr;
int j = *(++arr);

The stack space is not "deleted" in the same manner that would make the reference "fail with an invalid memory pointer". Instead, the stack space is available for re-use and the contents will probably change on your next call to a function.

In the meantime, the memory still exists, can be referenced, and should be considered to contain "Random Junk". In fact, it may very well contain the values that you expect but you should consider that as purely accidental and at the whim of the compiler / library / OS, in other words, nothing you can count on.
ggupta2009 14-Jul-11 2:04am
Thanks Chuck..
so, if I want to create array inside a function surely, I need to use dynamic allocation.
Emilio Garavaglia 14-Jul-11 2:52am
Every time you've to create something for somebody-else use you have to choices: dynamic allocation (so that what you create will survive the scope boundaries) or copy-on-return. The problem with arrays is that the compiler doesn't do that automatically since in general inefficient.

But for relatively small arrays, if you wrap them into a struct
(like struct ten_ints { int ints[10]; }; you get something that can be copied, so that you can do ten_ints z; return z; and be even more efficient than a dynamic allocation/deallocation that may result in processor page fault in caching. With modern processors, the tradeoff if around 500 bytes.
John R. Shaw 14-Jul-11 21:20pm
In your example - you could simply make the array "static int arr[10]" - as long as it is not changed by the next call to the function, there is no problem.

If you are going to allocate memory, then you might as well use vector. To avoid copy on return - pass a reference to a vector as an argument - it's more efficient.
Harrison H 14-Jul-11 14:06pm
What? Unless he overwrites the copy constructor on that struct, there's no guarantee what's inside of that array on a shallow copy.
Philippe Mori 16-Jul-11 18:41pm
Not true. Compiler generated copy constructor and assignment operator will correctly copy a fixed array. It would be incorrect if no size where specified (int ints[]or a pointer was used which is essentially equivalent).
The array exists until it is deleted. You can't trust it to be there, but it is, for now. In other words, the memory it sits in, is available for use, but it's not been used yet, so it is returning the values you expect. But, if you relied on them later, the values could change.
ggupta2009 14-Jul-11 2:03am
Thank you very much Christian..
I got my answer
Harrison H 14-Jul-11 14:05pm
What? Christian, that is a very confusing answer. The short answer is if he wants to return an array he has to allocate it on the heap (via new) and clean it up himself later (via delete).

An even better answer would have him use vectors since he doesn't understand arrays.
John R. Shaw 14-Jul-11 21:04pm
Read the question. Christian has it right. The question was "I am not getting any error why?". In other words, why was there no error when accessing the array after it was popped off the stack [deleted].

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900