[Development] Move ctors for q_declare_shared types
Olivier Goffart
olivier at woboq.com
Fri Jun 26 16:33:00 CEST 2015
On Friday 26. June 2015 16:14:48 Olivier Goffart wrote:
> On Friday 26. June 2015 15:42:31 Daniel Teske wrote:
> > > > 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.
>
> I partially disagree.
> The wording seems to indeed implies that the move assignement operator of
> std::vector should do iterate over all elements to destroy or move them. But
> in practice, GCC implementation does not do that:
> http://cpp.sh/2s4w
Sorry, I was wrong.
As Julien pointend out, i reversed the two side of the equality.
> Is it a bug in the GCC's stdlib implemenation? Or is it a misunderstanding
> of the wording of the standard?
>
> > - QVector does not give the same guarantee, because it uses swap.
>
> Irrelevant.
So indeed, QVector is different and do not have this garentee.
>
> > - QVector should give the same guarantee as the standard containers.
>
> I disagree with that. QVector is not std::vector. At first, it is implicitly
> shared, so that's already a big difference. And therefore we can allow
> ourselfs many more differences.
But this point still stands.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
More information about the Development
mailing list