[Development] Container refactor update
marc.mutz at kdab.com
Thu Jun 21 09:36:29 CEST 2012
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
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? :)
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
More information about the Development