[Development] Move ctors for q_declare_shared types

[André Somers]

Daniel Teske schreef op 26-6-2015 om 12:34:
>> Most of our implicitly shared types already had a move-assignment operator,
>> because it's just
>>
>>     QFoo &operator=(QForr &&other) { swap(other); return *this; }
> And that's indeed how QVector's move assignment is implemented.
>
> It's also broken.
>
> Just because other is a rvalue reference does not mean that it is a temporary
> and thus the is no guarantee that other's dtor gets called.
>
> And thus, this line:
>
> QVector<Klass> vector = std::move(something);
>
> does not gurantees that the dtors for the old contents of vector are called.
Perhaps I am off-base here, but it seems to me that no such requirement 
is needed. After all, at some point _something_ will go out of scope. 
That's when the destructor will be called. If you use std::move, you 
tell the compiler to treat its argument as a temporary. It seems to be 
that you also assume the responsibility that you will deal with it as 
such, including making sure it will get destroyed.

>
> For standard containers, this is specified in *container.requirements*
> To quote, with: a being a container and rv a non-const rvalue of the same
> type:
>
> a = rv
>
> "All existing elements of a are either move assigned to or destroyed,"
>
> I do not see any reason why our containers should not give the same guarantee
> for move assignment and consider this a bug.
Is this really that much different? A move assign of an element also 
doesn't guarantee destruction of the assigned-to contents right then and 
there, right? This again may be implemented as a swap.

Perhaps I am missing some subtlety here, but I don't see the problem.

André