return reference to local variable ?

[romerun]

Hello,

This make me very confusing:

----------------------------------
int &kkk() {
int a = 5;
return a;
}

int main() {
int b = kkk();
}
----------------------------------

"b" should be undefined as many articles say. However, I have tested
in g++ and Visual C++, the result of b is 5 !?

I guess g++ and Visual C++ choose to implement the "undefined" state
in this case as trying to get the value of the reference to local
variable thereby making "b" has the expected result

I'm I wrong ?

 

[Alf P. Steinbach]

* romerun:

Hello,

This make me very confusing:

----------------------------------
int &kkk() {
int a = 5;
return a;
}

int main() {
int b = kkk();
}
----------------------------------

"b" should be undefined as many articles say. However, I have tested
in g++ and Visual C++, the result of b is 5 !?

I guess g++ and Visual C++ choose to implement the "undefined" state
in this case as trying to get the value of the reference to local
variable thereby making "b" has the expected result

I'm I wrong ?

Yes.

It's simply that nothing has yet corrupted the memory area that the local
variable occupied, at the point where the value is used.

There is no guarantee for that and it might turn out differently with
different compiler options (not to mention different compilers).

 

[Karl Heinz Buchegger]

Hello,

This make me very confusing:

----------------------------------
int &kkk() {
int a = 5;
return a;
}

int main() {
int b = kkk();
}
----------------------------------

"b" should be undefined as many articles say. However, I have tested
in g++ and Visual C++, the result of b is 5 !?

I guess g++ and Visual C++ choose to implement the "undefined" state
in this case as trying to get the value of the reference to local
variable thereby making "b" has the expected result

I'm I wrong ?

Yep.
The above works just per coincidence.
In this particular program the memory state of the
program hasn't changed enough and thus you get the
result you expect. But as said: This is just a
coincidence in this special case. It is *not*
because the compiler writers tryed to help
you in some clever way.

When a variable goes out of scope, we say the variable
is destroyed. Well. That's what we say. But in a computer
acutally nothing is physically destroyed. The variable
was assigned a memory location and that memory location
holds the value. So when a variable gets destroyed, its
corresponding memory location is marked as beeing free
but that's it. The memory location still holds the value,
until the program uses it for something else.

 

[Derrick Coetzee]

int &kkk() { int a = 5; return a; }
int main() { int b = kkk(); }

"b" should be undefined as many articles say. However, I have tested
in g++ and Visual C++, the result of b is 5 !?

In this particular case it's 5 only because that particular location has
been freed but not yet reused. Not only is this specific to this
program, compiler, and set of compiler options, but if you hold onto the
reference which is returned, insert a call to another function, and then
check the value of b, you'll see how fragile this behaviour can be:

#include <iostream>
int &kkk() { int a = 5; return a; }
void jjj() { int d = 10; }
int main() {
int& b = kkk();
jjj();
std::cout << b;
}

Although the output of this program is undefined, on your platform with
optimizations off it's likely to output 10.

 

[romerun]

Yep.
The above works just per coincidence.
In this particular program the memory state of the
program hasn't changed enough and thus you get the
result you expect. But as said: This is just a
coincidence in this special case. It is *not*
because the compiler writers tryed to help
you in some clever way.

When a variable goes out of scope, we say the variable
is destroyed. Well. That's what we say. But in a computer
acutally nothing is physically destroyed. The variable
was assigned a memory location and that memory location
holds the value. So when a variable gets destroyed, its
corresponding memory location is marked as beeing free
but that's it. The memory location still holds the value,
until the program uses it for something else.

Do you have cases of "return ref to local var" that doesn't work (in g++ or vc++) ?

 

[Richard Pennington]

Do you have cases of "return ref to local var" that doesn't work (in g++ or vc++) ?

If you tried this in an environment that allowed multiple threads of
execution, it is guaranteed to fail. Usually at a bad time.

-Rich

 

[Alf P. Steinbach]

* romerun:

Do you have cases of "return ref to local var" that doesn't work (in g++ or vc++) ?

To corrupt the memory formerly occupied by the variable, simply evaluate
an (suitable) expression involving variables that cannot be optimized
away, or pass the reference to a function that has its own locals.