[Development] Container refactor update

[Marc Mutz]

On Thursday June 21 2012, Thiago Macieira wrote:
> On quarta-feira, 20 de junho de 2012 08.52.55, Marc Mutz wrote:
[...]
> > So, can we please just have the equivalent of
> >   template <typename T>
> >   using QList = QVector<T>;
> > after moving the members that QList has but QVector lacks over to
> > QVector?
>
> My plan is *almost* that.
>
> QList<T> will be a QVector<T> if
> 	sizeof(T) < 32
> 	T is movable
>
> Otherwise, QList<T> will be backed by a QVector<T *> and the pointer will
> be dereferenced in the accessor functions.
>
> The value of 32 is chosen because it will be the size of QVariant on 64-bit
> platforms.

You meant
   sizeof(T) <_=_ 32   _||_   T is movable,
right?

Assuming move constructors become ubiquitous on types that you'd want to put 
into a homogeneous container, I wonder if a special case for large or 
non-movable types is needed at all.

After all, a non-movable type can still have a a rather fast move constructor 
(assuming vector uses them on reallocation in preference over copy 
constructors (which it currently doesn't do since *it++ isn't an rvalue)): in 
the case of q-pointers in the Private class, e.g., the public class' move 
ctor would simply adjust the q-pointer, which would require quite a few moves 
before the free-store access wins out with its trivially copyable payload. 
That is on top of the locality-of-reference problems and memory overhead that 
free-store allocations incur.

For classes where free-store allocation would be better, I think it's 
reasonable to assume that users would hold them in (smart) pointers anyway.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions