Why isn't the lifetime of the temporary extended in this case?

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? Why isn't
the reference extending the lifetime of the object anymore? Why does the
reference extend the lifetime of the return value of getMyClass(), but
not the lifetime of the return value of MyClass::print()? How does it
make even sense that a reference can be created to an object which is
destroyed immediately after the reference is created?

re: Why isn't the lifetime of the temporary extended in this case?

Juha Nieminen wrote: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.
Because the language does not require it.
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.
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

re: Why isn't the lifetime of the temporary extended in this case?

Juha Nieminen <nospam@thanks.invalidkirjutas:
[...]
itselfthegetMyClass() returns an object; MyClass::print() returns a reference.
Presumably, if a function is returning a reference to some object, then
it means the object lives somewhere else, i.e. the lifetime of the object
is maintained elsewhere and the caller should not worry about that.

OTOH, if a function returns an object, then its lifetime cannot be
maintained by the function itself and will be the responsibility of the
caller. C++ provides a facility for maintaining the object lifetime in
this case, namely binding to a const reference. This is a special case
introduced exactly because there would be no solution otherwise (without
copying the object, which might be impossible or unacceptable).

Warning generation is a quality of implementation issue. The creation and
destruction of the temporary object are here interspersed with a call to
the print() method, which might complicate the things for compiler (if
print() is not inlined, it would be very hard to detect the error). But
yes, having a diagnostic for such things would be nice.

regards
Paavo

re: Why isn't the lifetime of the temporary extended in this case?

Victor Bazarov wrote:But I thought the whole idea of references is that they would be safer
than pointers.

re: Why isn't the lifetime of the temporary extended in this case?

>class MyClass[...]I didn't quite understand this. Do you say that the call:
obj.Print(2);
is an undefined behavior?

Would this:
MyClass const& bad = pass(pass(pass(pass(MyClass()).print(3))));
be UB as well?

re: Why isn't the lifetime of the temporary extended in this case?

anon wrote:Well, it's actually

obj.print(2);

and, no. The return value of 'Print' is not being used in any way.
Nope. But any attempt to *use* 'bad' would.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask