Thank goodness default move constructor/assignment was added to the (draft) standard.

Great read, thanks for the series.

Not in this case. You forget that there’s a std::swap overload for std::vector.

More-so than performance issues, I think that it is too bad that the canonical move assignment operator relies on a specialized definition of swap, since the promise of “if your type is movable, you can just use the default std::swap” was a big benefit. Now its a chicken and egg thing for canonical swap (need swap for move, need move for swap).

It would make sense for adapting a legacy type that had already implemented swap, but one of the real points of this article is that there really isn’t a suitable “canonical move assignment.”

Hopefully most of the time the “= default” move operators will suffice, and when they don’t, hopefully writing a specialized move operator is warranted anyway. As a side note, the only other reason I can think of to still write a swap member is to allow swap-with-temporary. So, could swap-with-temporary be replaced with move assignment? T().swap(t) t = T(); ? The only times I used swap-with-temp before was for non copyable objects or when copy semantics were insufficient (ie, shrinking vector capacity). Seems move assignment covers those basis?

Probably.

More-so than performance issues, I think that it is too bad that the canonical move assignment operator relies on a specialized definition of swap, since the promise of “if your type is movable, you can just use the default std::swap” was a big benefit. Now its a chicken and egg thing for canonical swap (need swap for move, need move for swap).

Hopefully most of the time the “= default” move operators will suffice, and when they don’t, hopefully writing a specialized move operator is warranted anyway.

As a side note, the only other reason I can think of to still write a swap member is to allow swap-with-temporary. So, could swap-with-temporary be replaced with move assignment? T().swap(t) <=?replaceable?=> t = T(); ? The only times I used swap-with-temp before was for non copyable objects or when copy semantics were insufficient (ie, shrinking vector capacity). Seems move assignment covers those basis?

Generally, I think it is likely worth the effort to squeeze cycles out of std::vector but I think it is much better to teach the formulaic “pass by value and swap” assignment because it is so much easier to get correct. I’ve come across a lot of code that blows the self-assignment case.

Thanks.

I finally look at the source, and it turns out that I misunderstood the comment “libstdc++ (the GCC standard lib) has optimizations that can…” and was confused about what a move iterator is.

So, actually :

1) make_move_iterator have nothing to with that memmove optimization. memmove is called when the iterator value type is a pod, nothing else.

2) A move iterator is an iterator adaptor. (I missed that part )

3 )

std::copy(std::make_move_iterator(rhs.begin()), std::make_move_iterator(rhs.end()), begin());

is a verbose way to write :

std::move(rhs.begin(), rhs.end(), begin());

template <class X>
template <class Y> shared_ptr<X>&
shared_ptr<X>::operator=(shared_ptr<Y> &&r)
{
     shared_ptr( std::move(r) )
         .swap(*this);
     return *this;
}

As for MSVC 10, that would be a bug in their implementation. rhs is supposed to be treated in expressions as a non-const lvalue, so _Ty should be deduced to be alloc, not const alloc.