A very good and informative article. Thanks!

I've read your blog post. It was most unnecessary.

Clearly you do not understand the ramifications of this addition so why clutter the internet with that information?

People who complain about nuisances at least care a little about a thing. Those who don't have abandoned it. BTW, the desired article has been written, see esp. question 3 http://www.bookpool.com/ct/98031 .

Now you can try it out in gcc 4.3.

> Since the creators of the language visit this board, could
> they please drop a few comments on the viability/usability
> of the move semantics on the programming language
> perspective level? methinks it's a bad move, because of
> all the problems of move semantics as we know them from
> std::auto_ptr...

I consider std::auto_ptr a pioneer in the area of move semantics. There is one very important detail it got wrong (and had little choice given the lack of language support in C++98): It moves from lvalues.

The move semantics framework in C++0X will not implicitly move from lvalues (with a couple of exceptions noted below). It will only move from rvalues. When you move from an rvalue, no other part of your program will notice because if you know you have a reference to an rvalue, then you also know that no other part of your program is referencing that rvalue.

Exception 1:

Sometimes it is advantageous for the programmer to be able to say: "treat this lvalue as an rvalue for this one operation". The programmer might want to do this when he knows (for example) that right after he "copies" from x, he is going to assign a new value to it, or destruct it anyway. So the old value of x is no longer valuable to the program logic (except as "copied" to the new location). A prime example is when vector reallocates its buffer. There is no need to copy values from the old buffer to the new; they can often be much more efficiently moved from the old buffer to the new buffer. To do so, the author of vector must explicitly specify the operation as a move since the values in the old buffer are lvalues.

Exception 2:

When copy elision is legal, but unable to be performed, an implicit move from an lvalue can be performed. Example:


A foo(bool b)
{
A a1, a2;
if (b)
return a2;
return a1;
}


In the above example, it is legal but exceedingly difficult for the compiler to perform Return Value Optimization. In C++0X the compiler will treat a1 and a2 as rvalues in the return statements. If A has a move constructor, it will be used. Else if A has a copy constructor it will be used. Else the program is ill-formed.

The result of these rules is that some programs which make heavy use of STL or other move-enabled libraries may simply start to execute much faster by simply recompiling in C++0X: with no changes needed, with no rvalue reference or move in sight, and no change in semantics. However in the interest of backwards compatibility, for the user's own classes to start moving, he will have to explicitly code move constructors and move assignment. When he does so, the framework is designed so that his clients will simply experience increased performance, and not a change in semantics.

Further background information regarding move semantics and auto_ptr can be found here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.4.5%20-%20Class%20template%20auto_ptr

The most important points of this link are:

1. One should not move from lvalues using copy syntax. Other syntax for moving should be used instead. Otherwise generic code is likely to initiate a move when a copy was intended.

2. Even though it is unsafe to move from an lvalue with copy syntax, it is both safe and desirable to move from an rvalue with copy syntax. When an rvalue binds to a function, that function has a unique reference to the rvalue and thus can safely modify it.

Hi all,

I was trying to get familiarity with the concept of Rvalue references. While reading this article, the definition of forward has something I can't understand: the need for identity<T>::type:


template <class T>
T&& forward(typename identity<T>::type&& a)
{
return a;
}


Why can't it be done simply as the following?


template <class T>
T&& forward(T&& a)
{
return a;
}


I'm sure I'm missing something, but I can't figure it out.

In http://www.pdc.kth.se/training/Talks/C++/boost/libs/mpl/doc/index.html it can be read


// on the face of it, not very useful
template< typename T >
struct identity
{
typedef T type;
}


I also took a look at http://www.boost.org/doc/libs/1_36_0/libs/mpl/doc/refmanual/identity.html.

On the other hand


template <class T>
typename remove_reference<T>::type&&
move(T&& a)
{
return a;
}


does the its thing the other way round: using some MPL techniques for the return value and not for the argument's type.

Thanks a lot in advance.

Rodolfo.

> Now I wonder, should the next version of the standard
> library still provide overloads of std::swap
> for all of the STL containers? It looks like the most
> generic version, template <class T> swap(T&
> a, T& b), should be good enough by then!

Thanks for your kind comment Niels. To answer your question above, No. Explanation:

You are right that the generic swap is *much* more efficient now, using move construction and move assignment. However the generic swap is still 2-3 times as expensive as the overloaded swap for vector (for example). For quick coding/prototyping and for non-performance critical code, the generic swap can be much faster now (if the class provides move constructor and assignment). But std::containers such as vector are used *so* much that attention to detail is paramount. Thus even "twice as fast as blazingly fast" is worth a few extra lines of code.

Details: vector move construction, move assignment and swap are all approximately the same cost. The generic swap will do one move construction and two move assignments.

>
> I wonder how the heck can an article end up on Artima,
> signed by Bjarne and have a serious programming error in
> it???
>

By being a simple copy of a standards document focussed on a single topic written for relative experts. I would like to have had time to write a "perfect" article aimed for a more general audience, but there were no time and much demand.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

and of course: sorry.

> I wonder how the heck can an article end up on Artima,
> signed by Bjarne and have a serious programming error in
> it???
>
> I talk about the exception safety of the clone_ptr
> assignment operator. Honestly, who write this article?

I did. And you are correct that there is an exception safety bug in this assignment operator. My apologies.

This paper was originally a committee paper aimed at getting this language feature accepted, and not targeted to Artima. This detail was not important to the original goal of the paper.

> What do the 10+ people on the editorial board do, if this
> s gets published?

They work hard at their day jobs and volunteer what little time they have left over (if any).

> So PLEASE, change this:
>
> clone_ptr& operator=(const clone_ptr& p)
> {
> if (this != &p)
> {
> delete ptr;
> ptr = p.ptr ? p.ptr->clone() : 0;
> }
> return *this;
> }
>
> to something like this:
>
> clone_ptr& operator=(const clone_ptr& p) {
> if (this == &p) return *this;
> T *ptrt== p.ptr ? p.ptr->clone() : 0;
> delete ptr;
> ptr=ptrt;
> return *this;
> }

I would have no objections to this change. Another acceptable possibility is:

clone_ptr& operator=(const clone_ptr& p)
{
if (this != &p)
{
delete ptr;
ptr = 0;
ptr = p.ptr ? p.ptr->clone() : 0;
}
return *this;
}

Walter Karas wrote:
> Consider this code:
>
> extern void foo(A &a);
> extern void foo(A &&a);
>
> void bar(void)
> {
> A a,*ap = new A;
>
> foo(*ap);
> delete ap;
>
> foo(a);
> }
>
> Would the compiler be required or allowed to use the
> second overload of foo() for either of the two calls to
> foo() in bar() ?

No. 'a' and '*ap' are not rvalues, so in your example, foo(A&&a) will never be called.


> Separate question: was consideration given to requiring
> functions that take a rvalue reference to be equivalent to
> an explicit destructor call on the object? And, in a
> question related to that question, does/should the
> Standard require that this:
>
> ap->~A();
> delete static_cast<void *>(ap);
>
> work?

I guess N1377 section "Alternative move designs" might be of help to you:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Alternative%20move%20designs

Happy programming!

-- Niels