On Monday, 17 de October de 2011 10:18:16 João Abecasis 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 > Option 4: Move the decision out of QList<T>, so that there's a default > policy does what we want for the types you mention, but we still allow > users pick the behaviour for their own types. This would also allow us to > tweak the strategy for future types.
I don't like the idea of having extra template parameters to our container
classes. That makes forward-declaring them more difficult and it creates the
problem that SCARY iterators is trying to solve in STL (post-C++11).
The other option is to have a traits class that is automatically used, like
QTypeInfo. That is more amenable. We just have to remember that for a given
QList<T> used in Qt 5.0, the allocation strategy cannot change until Qt 6.0.
We can only change the rules for new types T that weren't used in previous Qt
versions.
Anyway, I think the best option is that QList<T> become a simple wrapper over
either QVector<T> or QVector<T *>, adapting the API, and I think we agree on
that.
It only remains to be seen how to make the selection.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
