[Development] Container refactor update

[Marc Mutz]

On Thursday June 21 2012, Thiago Macieira wrote:
> On quinta-feira, 21 de junho de 2012 08.26.23, Marc Mutz wrote:
> > You meant
> >    sizeof(T) <_=_ 32   _||_   T is movable,
> > right?
>
> Yes and no.
>
> sizeof(T) <= 32 && T is movable
>
> > 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.
>
> I'll add move support to QVector.
>
> But I want QList to always use realloc. If your type can't be realloc'ed,
> then QList should indirect.

What's the rationale for this design choice?

But whatever it may be: May I ask you to reconsider?

The movable trait (as in Q_MOVABLE_TYPE, not T&&) is nothing a compiler can 
automatically detect, not even theoretically (consider out-of-line copy 
ctors, e.g.).

So when you say "T is movable", what you really mean is "T is _declared_ 
movable by the user".

The fact that T needs to be declared movable for QList<T> to not use 
per-element free-store allocations then means that the Qt *default* container 
performs "horribly" (quoting yourself) for *all* types except if the user 
takes *manual* action (which might not be easy to do if the type in question 
doesn't have yet a Qt dependency, e.g. if it comes from a third-party 
library; there'll be no got place to put the required Q_DECLARE_TYPEINFO).

I consider this API the wrong way around, don't you? :)

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