return reference to local variable ?

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 ?

* 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).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

romerun wrote:
>
> 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.

--
Karl Heinz Buchegger

romerun wrote:
> 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.
--
Derrick Coetzee
I grant this newsgroup posting into the public domain. I disclaim all
express or implied warranty and all liability. I am not a professional.

Karl Heinz Buchegger <> wrote in message news:<>...
> romerun wrote:
> >
> > 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.

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

romerun wrote:

> Karl Heinz Buchegger <> wrote in message news:<>...
>
>>romerun wrote:
>>
>>>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.
>
>
> 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
--
Richard Pennington
Email:
http://www.pennware.com ftp://ftp.pennware.com

* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?