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>

1 files changed, 6 insertions, 0 deletions

diff --git a/tests/auto/corelib/tools/qeasingcurve/tst_qeasingcurve.cpp b/tests/auto/corelib/tools/qeasingcurve/tst_qeasingcurve.cpp
index 1d4e91dc00..40e3cd08b6 100644
--- a/tests/auto/corelib/tools/qeasingcurve/tst_qeasingcurve.cpp
+++ b/tests/auto/corelib/tools/qeasingcurve/tst_qeasingcurve.cpp
@@ -780,6 +780,12 @@ 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;
     const QEasingCurve::Type type = copy.type();
     copy = std::move(ec); // move assignment op