«

I thought that integers resized on the stack and that a value type was
just defined in the scope of the function. And when the function
returns the local variables were removed from the stack. But what is
the explication of this code??

int& dangling_reference();

int main(int argc, char *argv[])
{
int a;
a= dangling_reference();
cout<<a<<endl;
cin.get();
}



int& dangling_reference() {
int x=3;
return x;
}

"Hans Van den Eynden" <> wrote in message
news: om...
>I thought that integers resized on the stack and that a value type was
> just defined in the scope of the function. And when the function
> returns the local variables were removed from the stack. But what is
> the explication of this code??
>
> int& dangling_reference();
>
> int main(int argc, char *argv[])
> {
> int a;
> a= dangling_reference();
> cout<<a<<endl;
> cin.get();
> }
>
>
>
> int& dangling_reference() {
> int x=3;
> return x;
> }

That code has undefined behaviour, because you are using a reference to an
object that has been destroyed. What were you expecting? What do you see?

john

"Hans Van den Eynden" <> wrote in message
news: om...
> I thought that integers resized on the stack and that a value type was
> just defined in the scope of the function. And when the function
> returns the local variables were removed from the stack. But what is
> the explication of this code??
>
> int& dangling_reference();
>
> int main(int argc, char *argv[])
> {
> int a;
> a= dangling_reference();
> cout<<a<<endl;
> cin.get();
> }
>
>
>
> int& dangling_reference() {
> int x=3;
> return x;
> }

This is UB. If you are getting the correct result (printing "3"), then
you're just lucky. This probably occured because your program is small and
the contents of the memory address of 'x' are still intact. Regardless, you
should not *expect* your code to work.

Method Man wrote:
>
[snip]
>
> This is UB. If you are getting the correct result (printing "3"), then
> you're just lucky.



Some would say: He was unlucky.
The reason: If he were lucky, the program would have crashed immediatly
indicating that there is a problem somewhere. So he is unlucky in that there
is a problem which was not found during testing and waits as a time bomb for
the moment the end user first tries that program (and according to Murphy
crashes immediatly)

--
Karl Heinz Buchegger

Hans Van den Eynden posted:

> I thought that integers resized on the stack and that a value type was
> just defined in the scope of the function. And when the function
> returns the local variables were removed from the stack. But what is
> the explication of this code??
>
> int& dangling_reference();
>
> int main(int argc, char *argv[])
> {
> int a;
> a= dangling_reference();
> cout<<a<<endl;
> cin.get();
> }
>
>
>
> int& dangling_reference() {
> int x=3;
> return x;
> }


The following would be valid:

int& Blah()
{
int &x = *new int(3);

return x;
}


But then ofcourse the calling function would have to call "delete".

In circumstances like this, think to yourself, "Could I use a pointer
here?". If the answer's no, then you can't use a reference either. For
instance, the following may be more obviously invalid to you:

int* Blah()
{
int x = 7;

return &x;
}


A lot of compiler's warn you when you do the above.


Warning: line 5: Returning reference to local object


-JKop

> A lot of compiler's warn you when you do the above.


No, I'm not illiterate, that was a typo! "compilers".


-JKop