QEasingCurve: implement move constructor

The move constructor sets other.d_ptr to zero. This is safe, because
after being moved from, the object is left in a state in which it
can be safely destroyed (delete nullptr is a no-op).

It cannot meaningfully be used anymore (most members will crash with
a nullptr dereference), but in most cases, the moved-from object
cannot be accessed anyway (not a named object), and if a named object
is moved from, it must have been through explicit std::move(), as in
the test case.

The STL makes better guarantees (moved-from containers are .empty()),
but I don't think it's worth introducing a null state into
QEasingCurve just for supporting a use-case that should be
considered a bug anyway.

Change-Id: I4115b7386cdea6960507da6843a0d0196d8e4139
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

src/corelib/tools/qeasingcurve.h

@@ -84,6 +84,7 @@ public:
 
     QEasingCurve &operator=(const QEasingCurve &other);
 #ifdef Q_COMPILER_RVALUE_REFS
+    QEasingCurve(QEasingCurve &&other) : d_ptr(other.d_ptr) { other.d_ptr = 0; }
     QEasingCurve &operator=(QEasingCurve &&other)
     { qSwap(d_ptr, other.d_ptr); return *this; }
 #endif

tests/auto/corelib/tools/qeasingcurve/tst_qeasingcurve.cpp

@@ -778,6 +778,12 @@ void tst_QEasingCurve::testCbrtFloat()
 void tst_QEasingCurve::cpp11()
 {
 #ifdef Q_COMPILER_RVALUE_REFS
+    {
+    QEasingCurve ec( QEasingCurve::InOutBack );
+    QEasingCurve copy = std::move(ec); // move ctor
+    QCOMPARE( copy.type(), QEasingCurve::InOutBack );
+    QVERIFY( *reinterpret_cast<void**>(&ec) == 0 );
+    }
     {
     QEasingCurve ec( QEasingCurve::InOutBack );
     QEasingCurve copy;