Boost logo

Boost :

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;

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at