[boost] Re: Perfect Forwarding (almost)

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