Re: Binding temporaries to const references
"Jens Auer" <jens.muaddib@googlemail.com>
It is bound alright. Then immediately after that the full expression is
over, the temporary is nuked, and you have mReference dongling. The
full-expression is
mReference(A(1))
I stated that incorrectly, the temporary bound here actually lives until the
ctor exits. But for your purposes it is exactly as dongling.
Maybe I should rephrase my question. I know that the standard says
this, that is why I quoted it.
The stuff relevant to your case is in the next paragraph, 12.2p5. Listing
all the cases.
But I don't get the intention why it is
ok to bind a temporary object to a non-const reference in
{
T const& constRef = returnTempObject();
}
but not when I initialize a member reference:
class ConstRefMember
{
public:
ConstRefMember(): mRef(TempObject()) {}
T const& mRef;
};
If you actually understand what the standard says and query why it is
specified that way, ask in comp.std.c++. This group is about the practical
use of what is specified.
My guess at the intention is that temporaries are supposed to be temporary.
They shall in no case outlive the stack frame they are created in. In the
baseline case they live even shorter, just until the ; after the expression
they appear in. In some cases it is extended to little later. But the upper
bound of that is the stack frame. That is the last point the compiler is
able to track the thing -- if not destroyed here the temporary would create
a leak. And no compiler-controlled code is supposed to be possible leaky,
it is the privilege of the user.
The compiler should be able to figure out the destructor and insert a
call to it in the class's destructor
Shall it? When the code for the dtor is generated, it does not know what was
bound to the member reference. The code in the ctor may not be present in
the translation unit at all.
, so why is this case not
supported? It seems not quite consistent with the other, allowed case.
I don't see any inconsistency, if you think with the compiler's hat on, and
limit to the context that is actually seen at some points...
I think that the exception for binding a temporary object binding to a
const reference was added to make it possible to pass temporary
objects to functions having const reference parameters, but I do not
see why it has to be forbidden when assigning them to members.
It is not forbidden, just not too practical that way. We use reference
members to bind to something outside the class, that has longer life.
The rules IMO go to the limits what is possible having compilation that
translates a function at a time and treat every other fuction as a black
box.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]