Re: issue with temporaries and const references
On 17/10/2010 12:09, Johannes Schaub (litb) wrote:
noir wrote:
Hello,
why does 2) below fail?
#include<cassert>
#include<string>
int main()
{
// 1) WORKS
std::string s = std::string("hello").append("world");
assert(s == "helloworld");
// 2) FAILS
const std::string& t = std::string("hello").append("world");
assert(t == "helloworld");
return 0;
}
My understanding about case 2) is:
- a temp string is created (OK)
- a non-const member (append) is called on the temp string (OK)
- a non-const reference to the temp string is returned by append (OK)
- the non-const reference is bound to a const-reference (OK)
- the const-reference extends the lifetime of the temp string until the
end of the block.
However, I see "t" contains trash when it is tested in the assert, so I
guess the destructor for the string has been called somewhere.
Any clues?
You can interpret the Standard as having two things that are called
"temporary". The Standard is not always clear what thing it refers to in all
places, apparently assuming the reader can deduce that from context.
The first thing is a temporary*object*. The reference that "append" returns
surely refers to that temporary object.
The second thing is a temporary*expression*. append does not return a
temporary expression. Temporary expressions are the ones that directly
represent the creation of a temporary object. I.e 'string("hello")'.
I doubt that this two-fold identity of "temporary" is actually intended by
the committee, but such is definitely present. Seehttp://www.open-
std.org/jtc1/sc22/wg21/docs/cwg_active.html#462 for a discussion where the
property of an*expression* that was temporary would have been lost, and
explicit wording needs added to restore that property. On the other side,
other wording like at [class.copy]/p15 uses the*object* property of
"temporary" when it says "when a temporary class object that has not been
bound to a reference (12.2) would be copied ...". In the end, I think this
is disgusting.
The issue you mention was posted by me to usenet months ago, but it wasn't
forwarded as an issue report to the committee it seems. (And since the
reflector mailing list is kept behind closed doors, I have no clue whether
the committee ever discussed it).
Could you expand on why this could be problematic/harmful? I was a bit
spooked by your post but after reading the active issue and thinking
about it I think I can make head or tails of it. When trying to bind a
reference to a temporary, the only thing we care about is that the
expression results in a temporary. As a property of an expression, this
allows the user _and_ the implementation to only consider that
expression and no further, correct? Whereas if we had to consider
'temporary' as a property of an object, both user and implementation
would have to inspect the details.
Given:
T const& t = expression(a0, ..., an);
As the property of an expression:
- if expression is a function call, we only need to check that the
signature is of the form T(Arg0, ..., ArgN) to know whether we have
temporary
- if it is a constructor call, we have a temporary
- operator comma is covered by your link (it inherits the temporary-ness
of the right-hand expression)
- what about the ternary operator? I admit I'm not so sure myself there
- other cases...?
As the property an object:
I assume the base case would be constructor calls, and we follow from there.
But what if the expression uses IO behind the covers? Can we
deterministically check whether the end result would be a temporary?
I suspect the bit of wording about temporary objects you mentioned
regarding [class.copy] is mumbo-jumbo legalese to allow implementations
to elide copies/moves with any sort of magic they want. Does the notion
appear elsewhere? Perhaps it could be reworded to avoid introducing the
notion altogether while keeping the intent, I don't know.
What I find also interesting is that the idiomatic way to write rvalue
qualified, chaining methods would be:
T // _not_ T&&
T::method(Arg0, ... ArgN) &&
{
return std::move(*this);
}
right? Which assumes a useful move constructor but that makes sense:
overloading on rvalue *this should be a special case, not the rule.
Furthermore you'd need a good case to even *need* this kind of
overloading: for std::string (which has a useful move constructor), I'd
sooner write:
std::string s = std::move(other_string.assign("world"));
than ask for an rvalue overload of assign, or write my own when dealing
with custom classes.