about return local address in function ?

[nor1]

Golden rule:
Never return the address of an automatic local variable from a function
Never return a reference to automatic local variable from a function

any one please me some example

int* func1(){
int* p;
int i = 20;
p = &i;
return p;
}

the example above is correct !!
why ? p is store address of i (whice i is local variable)
i understand allright or not ?
please give easy example
i am new in C++:confused:

[TheCPUWizard]

The return value will point to the address occupied by "i" when the function was active. However this address space was on the stack, which is now no longer reserved by func1() therefore the next function to be called, or even some local calculations will use this stack space, the contents of that memory location will be overwritten.

One often thinks that it is safe if you just use the pointer "quickly" after the function returns. While this will often work, it is NOT guaranteed. There are many system level activities which could overwrite the location in question between the return statement (in the function) and the (presumed) assignment of the return value to some variable.

Hope this helps.

For a really good, in depth explaination, see Scott Meyers "Effective C++" Item #23.

[galathaea]

Here are some additional points on stacks. The c++ standard does not really define a stack, but most processors do. It is a common method of passing arguments to a code section (function) in assembly. Another method is through general registers, which is faster but more difficult to implement generally since most operations done by the processor use the general registers and thus the parameters may change during execution of the function. As well, the general registers cannot hold large objects.

Here is how the stack works usually in a function call. A stack, first of all, is a data structure where variables can be pushed, and susequently reading (popping) the variables from the stack "removes" them in the order of first-in last-out (the most recent push is returned by a pop). Now, removing is not usually done destructively, particularly for function calls, since that takes time. Often all that is done is an update to the pointer which addresses the location of the end of the stack (called the stack frame). So, on a function call, all of the parameters of the call get pushed on to the stack. Then, very often, variables local to the function get pushed on to the stack as they are declared. When a function returns, it restores the stack frame to its position prior to the function call.

Now, after the procedure returns, the information in the stack used in the function will no longer be considered part of the stack (since the frame has been restored) and new variables may be pushed into the same location. Therefore, no guarantee exists as to how long pointers taken to those variables actually will point to valid data.

In fact, the c++ standard makes important statements concerning variables local to functions that should prohibit you from using their address outside of the function. This concerns variable lifetimes. It is important to learn that local variables (variables created directly from their type inside a local scope, without a "new" free store allocation or declaration as static) exist only for that scope, and will not be guaranteed to exist any longer. In fact, classes with non-trivial destructors will have their destructors called just prior to leaving the scope, meaning that any resources the object controls will no longer be available to that object (except of course if the object is broken and doesn't clean up its resource properly in the dtor).

Since the standard's prerequisites for function variable scoping coincide with the abilities of the processor's stack, nearly every implementation of c++ uses a stack-based method for function calls, but even if one was programming in c++ for a non-stack-based CPU, the language requirements should still prevent one from accessing the variable. In general, most people therefore refer to the local variable memory as the stack.

Now there are some other points about stacks on specific processors and operating systems that one should be familiar with as well (including things like each thread will often get its own stack, etc.), but I hope this gives a start in the right direction. I think it is important to understand these little pieces of what is going on behind the scenes to really begin to get more comfortable with the language...