[Development] Move ctors for q_declare_shared types

Daniel Teske Daniel.Teske at theqtcompany.com
Fri Jun 26 15:42:31 CEST 2015


 
> > 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? 
There's a huge difference between "either move assigned to or destroyed" and 
not doing that.

I'm not sure where you are disagreeing, so can you point out to which of those 
4 statements you don't agree?

- Standard containers guarantee that the old elements get either move assigned 
or destroyed.

- QVector does not give the same guarantee, because it uses swap.

- QVector should give the same guarantee as the standard containers.

> 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.
If your class is e.g. holding a resource, implementing move assignment as a 
swap is wrong. The old resource needs to be freed at the point of assignment. 
Doing otherwise makes it harder to reason about code.

For an example of that, see .e.g the shared_ptr in the C++ standard:

"shared_ptr(shared_ptr&& r) noexcept;
Postconditions: *this shall contain the old value of r. r shall be empty. 
r.get() == 0."


daniel



More information about the Development mailing list