[boost] Re: Perfect moving (almost)

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-09 16:13:43

Howard Hinnant <hinnant_at_[hidden]> writes:

> On Feb 9, 2004, at 11:33 AM, Peter Dimov wrote:
>
>> Peter Dimov wrote:
>>> Howard Hinnant wrote:
>>>> Reasoning:
>>>>
>>>> foo(A());
>>>>
>>>> expands to:
>>>>
>>>> foo(A(A()));
>>>
>>> No, it expands to
>>>
>>>     typedef A const CA;
>>>     foo(CA(A()));
>>>
>>> The difference is that a const_cast<A&> inside foo is now undefined
>>> behavior (whereas a direct binding would've made it legal.)
>
> That's not the first time I'm skimmed over one of Rani's posts too
> quickly and lived to regret it.  Thanks for the whap across the nose!
> :-)  <mental note, if Rani writes it, read at least 3 times and not in
> a hurry>
>
>> 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)

> Aside:  I'm sure there are dark corners of the standard that would
> need to be closely inspected and perhaps adjusted for the existence of
> the proposed rvalue reference.  Although I'd be thrilled to help, I'm
> a library expert, not a core expert.  The core experts will have to
> lead on the move proposal if it is to succeed.  Once core delivers the
> fundamental tool, I know what I want to do with it in the std::lib.
>
> Further aside:  I'm impressed by the cleverness of the
> C++98-compatible (or nearly so) move techniques that have surfaced
> (Mojo, enable_if-based, and even the old auto_ptr_ref solution).  But
> one of my overriding goals in the language-based move proposal was
> that move logic must be dirt simple to code because Joe Coder needs
> and wants this functionality in his own classes

<snip>
That's what I meant when I mentioned this was not the cleanest approach.

> Dealing explicitly with auxilary auto_ptr_ref-like classes when either
> using move, or when creating movable (and perhaps also copyable)
> classes was recognized as a possibility (just due to the existence of
> auto_ptr) but rejected as too complicated and tedious for general use.

Not to mention that my technique (and MoJo) require duplicating the
copy ctor.

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