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.m...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
