Thiago Macieira wrote: > 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).
I didn't suggest this. > 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. This is more like what I had in mind. > 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. If we take this idea further, we could even remove QList from the ABI, in the sense that it would be a convenience wrapper or templated typedef... QVector<T> and QVector<T *> would be the types popping up in function signatures (documentation should probably still show QList<T>, though). I wonder if that would reduce our code footprint in any way. > It only remains to be seen how to make the selection. Qt5ABI::QListAllocationPolicy<T> :-p João _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
