-1

Though a similar question has been asked Is it possible to deallocate a statically defined array? previously, I have a related query.

    int* foo()
    {
        int arr[3] = {1, 2, 3};
        return arr;
    }
    int bar(const int*)
    {
        doSomething with int*;
    }
    int main()
    {
        bar( foo() );
    }

When will the memory allocated to arr in foo() be deallocated? Is a statically allocated array like arr not usually automatic? This syntax seems to work though, so is the memory assigned to arr only deallocated after the completion of bar()? Or not even then? If not, how would I free it?

Edit: Sorry, forgot to include main. Yes, this appears to be a duplicate post.

Community
  • 1
  • 1
UserUnspecified
  • 101
  • 6
  • 4
    That's not a statically allocated array. It's an array with automatic storage duration, and using the returned pointer to it will result in fireworks. – Jon May 15 '14 at 12:33
  • 1
    If I remember correctly returning a pointer to a local variable is undefined behaviour, and it's up to the compiler. – scragar May 15 '14 at 12:34
  • I tried it and it seems to work, which is why I am so confused – UserUnspecified May 15 '14 at 12:34
  • 1
    That's [the thing with undefined behavior](http://stackoverflow.com/a/6445794/166749). – Fred Foo May 15 '14 at 12:36
  • What is the difference between a statically allocated array and an array with automatic storage duration? I thought the latter was just a subset of the former? – UserUnspecified May 15 '14 at 12:40
  • @UserUnspecified "statically allocated array" is an ambiguous term. Sometimes people use it as a "retronym", perhaps intending the meaning "any array which is not dynamically allocated". However, since C includes the keyword `static` and the term *static storage duration*, it is unclear to write "statically allocated". The array in this example does not have static storage duration; the standard terminology for it is *automatic*. – M.M May 15 '14 at 12:47
  • This `int bar(const int*){...}` isn't valid C. the function's parameter list isses the variable name for `const int *`. – alk May 15 '14 at 12:47
  • `bar()` does not call `foo()` nor the other way round. Why do you assume the de/allocation of `foo()`'s **locally declared** variables do interfere in way way with `bar()`? – alk May 15 '14 at 12:50
  • Short story: it is deallocated when you leave the function. Regarding why you still seem to get correct values outside the function, check the duplicate post. – Lundin May 15 '14 at 13:05

2 Answers2

2

Most likely, it will be created on the stack inside the call to foo. When foo exits, the stack pointer is reset. The array is considered no longer accessible.

You can still see it because your program owns the memory where the stack is. However, once something else gets pushed onto the stack, it will get overwritten.

So, you should not use it outside of foo.

001
  • 13,291
  • 5
  • 35
  • 66
2

Your array behaves like a normal variable, as it actually is one. The variable scope in C or C++ is usuablly definied by the current block, which is your function foo.

As your array arr lies within the stack-area of your programm you should never every return a pointer to a local variable.

The stack-memory section is invalidated after your foo function returns and so you would access to not permitted memory area if you dereference the return value of foo. This leads to undefined behaviour. So everything can break or nothing. But this is just not what you want.

If you want to return a more long living array, you allocate memory in the heap-memory-section by creating your array with new or malloc. Than you can access it after your foo-function returned. But you have to free or delete[] your array than by hand.

You should maybe read more about memory-layout in C/C++: http://www.geeksforgeeks.org/memory-layout-of-c-program/

Peter Ittner
  • 551
  • 2
  • 13