refrence from return value ?

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

given a prototye:
string foo();

What would be the diffrence in calling it, and assigning
the return value in

string a = foo();
vs
string &a = foo();

(is the last one even legal?)

 

[Nicolas Pavlidis]

given a prototye:
string foo();

What would be the diffrence in calling it, and assigning
the return value in

string a = foo();
vs
string &a = foo();

AFAIK the last version will lead to an segfault on the next try to read
from it. foo() returns a string, which is copied befor it is retured, so
a temporary object will be assignet to a reference, but the temporary
object will be dead after the assignement, and so the reference show to
anyway.

I did not try it out, but I think it will no work, but I'm no expert,
maybe my interpretation is wrong.

Kid regards,
Nicolas

 

[Karl Heinz Buchegger]

AFAIK the last version will lead to an segfault on the next try to read
from it. foo() returns a string, which is copied befor it is retured, so
a temporary object will be assignet to a reference, but the temporary
object will be dead after the assignement, and so the reference show to
anyway.

I did not try it out, but I think it will no work, but I'm no expert,
maybe my interpretation is wrong.

Well. Yes.
The guys writing the standard took provisions for that. The rule
is: The temporary lives as long as the reference to it lives.

But honestly: I wouldn't count on all compilers to implement this
correctly in all cases.

 

[Peter van Merkerk]

AFAIK the last version will lead to an segfault on the next try to read
from it. foo() returns a string, which is copied befor it is retured, so
a temporary object will be assignet to a reference, but the temporary
object will be dead after the assignement, and so the reference show to
anyway.

In this particular example the temporary object bound to the reference
will persist for the lifetime of the reference (see also the C++
Standard chapter 12.2). So no problem here.

Note that when a temporary object is passed by reference to a function
or constructor, the temporary object will only exist during the call.
Once the call has completed the temporary object will be destroyed, even
if the function or constructor has bound the temporary object to another
reference.

 

[John Harrison]

AFAIK the last version will lead to an segfault on the next try to read
from it. foo() returns a string, which is copied befor it is retured, so
a temporary object will be assignet to a reference, but the temporary
object will be dead after the assignement, and so the reference show to
anyway.

I did not try it out, but I think it will no work, but I'm no expert,
maybe my interpretation is wrong.

The code is not legal because a temporary cannot be bound to a non-const
reference. But there are no temporary lifetime issues here I think so.

const string &a = foo();

would be perfectly legal and OK.

john

 

[Sumit Rajan]

Well. Yes.
The guys writing the standard took provisions for that. The rule
is: The temporary lives as long as the reference to it lives.

Don't you think that would contradict 12.2/2. I'm quoting the relevant
line only (the whole thing sounds terribly confusing anyway -- like
everything else in the Standard):

A temporary bound to the returned value in a function return statement
(6.6.3) persists until the function exits.

Regards,
Sumit.

 

[Sumit Rajan]

Don't you think that would contradict 12.2/2. I'm quoting the relevant

^^^^^^^


Oops, sorry. That was 12.2/5 and not 12.2/2.

 

[Karl Heinz Buchegger]

Don't you think that would contradict 12.2/2. I'm quoting the relevant
line only (the whole thing sounds terribly confusing anyway -- like
everything else in the Standard):

A temporary bound to the returned value in a function return statement *************************

(6.6.3) persists until the function exits.

That's a different case.
We are not talking about what happens during the execution of the
return statement. The case under discussion happens after the function
has exited.

The above applies in situations like this

std::string foo()
{
return std::string();
}

Here a temporary string object is created for the return value. That temporary
exists until the function exits (has terminated). But that is very different
to what you actually do with the returned object:

const std::string& a = foo();

In foo()'s return statment a temporary was constructed. The return type of
foo() specifies that foo returns 'by value' thus a copy of that temporary
is to be made. And since that second temporary is bound to a reference, it
will live on as long as the reference exists. But the temporary created during
execution of the return statement is not the same temporary that gets bound
to the reference.

 

[Sumit Rajan]

That's a different case.
We are not talking about what happens during the execution of the
return statement. The case under discussion happens after the function
has exited.

The above applies in situations like this

std::string foo()
{
return std::string();
}

Here a temporary string object is created for the return value. That temporary
exists until the function exits (has terminated). But that is very different
to what you actually do with the returned object:

const std::string& a = foo();

In foo()'s return statment a temporary was constructed. The return type of
foo() specifies that foo returns 'by value' thus a copy of that temporary
is to be made. And since that second temporary is bound to a reference, it
will live on as long as the reference exists. But the temporary created during
execution of the return statement is not the same temporary that gets bound
to the reference.

I guess I had misunderstood your initial statement. Sorry for the trouble.