[boost] Re: Perfect moving (almost)

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-10 09:40:35

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> Howard Hinnant <hinnant_at_[hidden]> writes:
>>
>>> On Feb 9, 2004, at 11:33 AM, Peter Dimov wrote:
>>>
>>>> However (apologies for the follow up to self) the rest of Howard's
> analysis
>>>> still seems to apply, i.e. the CA temporary is created with A::A(A&&),
> and
>>>> the A const & parameter of foo is bound directly to that temporary
>>>> (if not elided).
>>>
>>> And thanks for the corrected analysis.
>>
>> I don't know.  If that analysis were correct, then Comeau would give
>> the same error for this snippet in my example.
>>
>>     typedef X const XC;
>>     sink2(XC(X()));
>>
>> but instead I see:
>>
>>  ------ test 20, direct initialize a const A with an A -------
>> X() #24
>> MOVE #25 <== #24
>> in const lvalue sink2
>> destroy #25
>> destroy #24 (EMPTY)
>
> That's because your "move" constructor is not a move constructor from
> language point of view (i.e. it has no special status). As I understand it,
> the compiler's thought process goes somewhat like: need to create a
> temporary, but it can be elided, so we'll just access check the copy
> constructor. The compiler doesn't want to backtrack and try not to elide the
> temporary, which would've succeeded.

OK, so 8.5.3/5 says:

  A temporary of type ``cv1 T2'' [sic] is created, and a constructor
  is called to copy the entire rvalue object into the temporary. The
  reference is bound to the temporary or to a sub-object within the
  temporary.* 

  [Footnote: Clearly, if the reference initialization being processed
  is one for the first argument of a copy constructor call, an
  implementation must eventually choose the first alternative (binding
  without copying) to avoid infinite recursion. --- end foonote]

  The constructor that would be used to make the copy shall be
  callable whether or not the copy is actually done. 

The problem here is, IIUC, that the implementors read that as saying
that, because "a constructor is called to copy..." that the
constructor used must be a copy constructor?

I don't understand why the converting constructor fails to be
considered when the templated SFINAE'd constructor *will* be used to
copy const lvalues.  Templated constructors are never "copy ctors"
either, IIUC.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com