From: David Abrahams (dave_at_[hidden])
Date: 2004-02-08 15:10:17
"Rani Sharoni" <rani_sharoni_at_[hidden]> writes:
> David Abrahams wrote:
>>> The example below shows a technique for perfect forwarding that seems
>>> to work with GCC 3.3.1. rvalues are always moved automatically, and
>>> lvalues are copied.
>>> may have missed something. *If* my example actually works other than
>>> this case, I'd like to try to get the rule lifted, and soon! This is
>>> by no means the cleanest route to move semantics, but it's probably
>>> the smallest "language extension" we'd ever need to get it, and might
>>> even be possible before C++0x
> I already mentioned during the improved auto_ptr discussions that I'm not
> smart enough to use the new trick in order to introduce move semantics. It
> seems that you amazingly did it!
It was indeed inspired by your auto_ptr implementation.
>>> Except for one rather important case, it works with Comeau (errors
>>> only in strict mode). The important case that causes the error
>>> clearly violates 12.2/1 of the standard, but see below.
> The problem with reference binding using conversion
> operator/constructor(i.e. X const& r = X()) is addressed in active DR #291
> (see Mr. Adamczyk note)
I'm not really sure what to make of that text.
> and AFAICT it was discussed during the MoJo days.
Yep. I knew about it then, but it's so easy forgotten when you're
hunting for the elusive "move"
> IMHO the current standard explicitly allows it (per 8.5.3/5/2/1) and EDG is
> not very consistent about it:
> auto_ptr<Base> const& r = auto_ptr<Derived>(); // accepted by EDG
> auto_ptr<Base> const& r = auto_ptr<Base>(); // rejected by EDG
I believe that those two cases use different rules. In the first case
you have an implicit conversion, while in the second case you only
have copy initialization.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk