Re: Why isn't the lifetime of the temporary extended in this case?
Juha Nieminen wrote:
Let's assume we have a class like this:
//---------------------------------------------------------
#include <iostream>
class MyClass
{
public:
MyClass() { std::cout << "constructor\n"; }
~MyClass() { std::cout << "destructor\n"; }
const MyClass& print(int i) const
{
std::cout << i << std::endl;
return *this;
}
};
//---------------------------------------------------------
Now, if I create a reference to a temporary instance of this class,
the lifetime of that instance will be extended for the lifetime of the
reference. For example:
//---------------------------------------------------------
int main()
{
std::cout << "Before\n";
const MyClass& obj = MyClass(); //*
std::cout << "After\n";
obj.print(2);
}
//---------------------------------------------------------
This program will print:
Before
constructor
After
2
destructor
This is even so if the temporary is the return value of a function.
For example, let's assume we have the function:
MyClass getMyClass() { return MyClass(); }
Now if we change the line marked with //* to this:
const MyClass& obj = getMyClass(); //*
the result will still be the same. So clearly the lifetime of the return
value of a function is extended by the reference.
Now comes the puzzling part, and my actual question. Suppose that we
change the line marked with //* to this:
const MyClass& obj = MyClass().print(1); //*
Suddenly the output changes:
Before
constructor
1
destructor
After
2
Now the temporary object is destroyed after the reference assignment
ends! The second print() call is now calling a destroyed object! (Oddly
gcc doesn't issue even a warning about this.)
The same is true for:
const MyClass& obj = getMyClass().print(1); //*
But why? Why does the print() function returning a reference to itself
change the semantics of the lifetime of the temporary object?
The temporary object lives (in this case) as long as the reference that
is bound *directly* to it. The bound reference lives only long enough
to initialise the other reference (the 'obj') in this case. Right after
that the lifetime of the [temporary] reference ends, so does the
lifetime of the temporary object bound to the [original] reference, the
one your 'print' function returns.
> Why isn't
the reference extending the lifetime of the object anymore?
Because the language does not require it.
> Why does the
reference extend the lifetime of the return value of getMyClass(), but
not the lifetime of the return value of MyClass::print()?
It does. But you're comparing the second-hand reference's lifetime and
there is no requirement that any reference initialised later from any
other expression is supposed to cause the temporary to live longer.
Imagine:
// using your 'MyClass' class
MyClass const& pass(MyClass const& arg) { return arg; }
MyClass const& bad = pass(pass(pass(pass(MyClass()))));
Some might think that it is the same reference initialised by binding it
to the temporary being passed in and out of the 'pass' function and
eventually put into the 'bad' reference. But it *isn't*! The argument
of the 'pass' function and its return value are *different references*.
The return value is initialised from the argument initialised from the
temporary. So, if the rule was only about binding a ref to a temporary,
the temporary would only lives as long as the argument of the very first
'pass' function (the inner-most). The "until the full expression is
evaluated" requirement would override that in this case, so you should
see the temporary report its destruction right after the last 'pass'
returns, just before 'bad' is initialised.
> How does it
make even sense that a reference can be created to an object which is
destroyed immediately after the reference is created?
The same way that a pointer can be created to an object that has already
been destroyed:
Object* foo(Object *p) {
delete p;
return p;
}
Any use of the return value of this 'foo' function will have undefined
behaviour.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask