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 <[email protected]> | 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
