[boost] Re: Perfect moving (almost)

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-02-09 11:12:07

On Feb 9, 2004, at 9:44 AM, David Abrahams wrote:

> One thing I think we overlooked in the move proposal, though, is the
> fact that "only movable and not copyable" class rvalues *still* can't
> legally be passed where a const reference is expected, unless the rule
> in question is lifted.  That seems like a problem to me.

I'm not sure I'm completely following, but let me try...

Given:

class A
{
public:
     A();
     A(A&&);
     ~A();
private:
     A(const A&);
     A& operator=(const A&);
};

(or perhaps more elegantly:

explicit class A
{
public:
     A();
     A(A&&);
     ~A();
};

:-)
)

and

void foo(const A&);

then the problem is:

foo(A());

?

Problem because 12.1 requires an accessible copy ctor even if the temp 
is elided?

I don't think this is a problem with the move proposal (of course 12.1 
would probably need to be clarified with the introduction of the rvalue 
reference).  Reasoning:

foo(A());

expands to:

foo(A(A()));

i.e. a temporary copy is at least conceptually created and then that is 
bound to the const A&.  In order to create the temporary copy, name 
lookup finds two possible signatures to create the copy:

A(A&&);
A(const A&);

Since the argument is an rvalue, the accessible A(A&&) is chosen over 
the inaccessible A(const A&), and so I see no problem.  Now the extra 
temporary can be elided, and in that case the original temporary is 
bound to foo's parameter.  Or, if the extra temporary is not elided, 
then the original temporary is used to move construct another temporary 
which in turn is bound to foo's parameter.  Either way, the result is 
the same (except for efficiency issues of move constructing an extra 
temporary), and the process is consistent with our existing process.

Or have I completely missed your point?

-Howard