[Development] QList

[Thiago Macieira]

On sábado, 18 de março de 2017 15:32:55 PDT Marc Mutz wrote:
> On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote:
> > QVector<MyType> someFunction()  // out-of-line
> > {
> > 
> >         QtExclusive::QVector<MyType> vector;
> >         [ operate and populate vector ]
> >         return vector;          // automatic move
> > 
> > }
> > 
> > in user code:
> >         QtExclusive::QVector<MyType> vector = someFunction();   //
> > 
> > automatic move [ mutate some more ]
> 
> Breaks (N)RVO.

How?

> And since the code outside has no clue about whether the code inside the
> function creates a shared or unshared QVector, the compiler will again have
> to emit the whole QVector copy constructor/detach code (as dead code) at
> the call site. You promised this would be gone in Qt 6 because of the
> removal of the unsharable state.

QtExclusive::QVector's move constructor for QVector always needs to emit 
copying code, since it doesn't know whether the data is shared or not. There's 
no way around that.

QVector's move constructor for QtExclusive::QVector simply adopts the data and 
starts reference-counting.

You could argue that a function that always returns an unshared vector could 
return QtExclusive::QVector. But we should not allow that in our API any more 
that we allow returning references.

> > Why not std::vector? Because of the ability to put it back into shared
> > mode,
> std::shared_ptr<const std::vector>

One level of indirection too many. We've been over this.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center