Add move semantics to RefPtr

Add move semantics to RefPtr

Add move constructors and move assignment operators to RefPtr when
COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES).
This obviates unnecessary reffing/ureffing when RefPtr is created
or assigned from rvalue references.

BUG=

[Mikhail, 2013-04-26 15:17:29]

Here is patch adding move constructors and move assignment operators to RefPtr
when COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES).
This obviates unnecessary reffing/ureffing when RefPtr is created or assigned
from rvalue references.

[eseidel, 2013-04-26 18:23:02]

CCing folks more familiar with new c++isms.

[Jeffrey Yasskin, 2013-04-26 19:56:46]

Of course, remember that it's still several months, at least, before we'll be
able to turn on C++11 mode, but I love the direction of the change. :)

https://codereview.chromium.org/14031031/diff/1/Source/wtf/RefPtr.h
File Source/wtf/RefPtr.h (right):

https://codereview.chromium.org/14031031/diff/1/Source/wtf/RefPtr.h#newcode48
Source/wtf/RefPtr.h:48: ALWAYS_INLINE RefPtr(RefPtr&& o) :
m_ptr(o.release().leakRef()) { }
This looks correct, but you're not getting much benefit from the ALWAYS_INLINE
here because neither release() nor leakRef() is ALWAYS_INLINE. It's not a big
deal, but I'd implement this more directly as:

 ALWAYS_INLINE RefPtr(RefPtr&& o) : m_ptr(o.m_ptr) { o.m_ptr = 0; }

That's also more obviously correct to people who aren't familiar with
PassRefPtr.

https://codereview.chromium.org/14031031/diff/1/Source/wtf/RefPtr.h#newcode49
Source/wtf/RefPtr.h:49: template<typename U> RefPtr(RefPtr<U>&& o) :
m_ptr(o.release().leakRef()) { }
In the long run, we'll probably want to enable_if this and the converting copy
constructor on is_convertible<U*, T*>, but that's not really relevant to this
change.

https://codereview.chromium.org/14031031/diff/1/Source/wtf/RefPtr.h#newcode87
Source/wtf/RefPtr.h:87: RefPtr& operator=(RefPtr&&);
I usually recommend writing operator= as

RefPtr& operator=(RefPtr other) {
  swap(other);
  return *this;
}

unless the implementation sometimes doesn't move an rvalue argument (libc++'s
std::string, for example).

I don't immediately see a reason to avoid that definition of operator= here, and
it would save a bunch of overloads and the use of std::move in the
implementation.

[Nico, 2013-04-26 19:59:17]

Even when we turn on C++11 everywhere, we won't allow all features immediately.

Do we get some measurable gain from this?

[Jeffrey Yasskin, 2013-04-26 20:04:19]

On 2013/04/26 19:59:17, Nico wrote:
> Even when we turn on C++11 everywhere, we won't allow all features
immediately.
> 
> Do we get some measurable gain from this?

It'll let us delete PassRefPtr once we turn on C++11 everywhere. Before then,
it'll only help where people forgot to use PassRefPtr and are building in C++11
mode.