Boost logo

Boost :

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

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