On 10/16/11 5:12 PM, "ext Olivier Goffart" <[email protected]> wrote:
>On Sunday 16 October 2011 16:21:40 Thiago Macieira wrote: >[...] >> Option 3: make it QList<T> be an actual QVector<T> for movable types, >>maybe >> with an upper limit of size (32 bytes, 128 bytes?). >> - pros: suitable for all types, shares code >> - cons: more complex to implement, more code to compile and parse in >> headers > >This is the obvious solutions... Yes, I'd be in favor of this solution as well. But it is the one that requires most work. I'm not sure it would be exactly a QVector<T>, but the data layout should be similar (ie. inline data). Hard to say what the upper size limit should be, as it depends on the usage pattern. Somewhere between 16 and 128 bytes sounds correct though. Cheers, Lars > >> One big difference between QList and QVector today is that QList has >>prepend >> / takeFirst optimisation, whereas QVector must move all elements to >> accommodate. I would prefer if that optimisation remained present. > >It has to (it enable QList to be used for queue like data structure (and >it >is, see QQueue) > >QList was also supposed to expands to less code (than QVector) (at least >that >is what Jasmin used to advertise some years ago) > >_______________________________________________ >Qt5-feedback mailing list >[email protected] >http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
