Howard Hinnant <hinnant@twcny.rr.com> 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