On 2017-04-25 20:45, Matthew Woehlke wrote:
On 2017-04-25 09:48, Thiago Macieira wrote:
Basically the discussion is: what should happen to QArrayList<int> or
QArrayList<void *>?
a) fail to compile
b) become an array list
c) become a vector
I point out that (c) is what QList does, and we don't need the same
behaviour
as QList already has.
Marc proposed (a), which is the simplest solution to the problem. I
wanted
(b), which would require duplication of code and Marc was unwilling to
do
that.
Why would a container type fail to compile for such basic types? For
what types *would* it compile? It would help for context if people
didn't have to read the review request.
(Okay, having gone and read the review request...)
FWIW, I think (b) makes more long-term sense... if we provide a
container type whose purpose is to makes explicit guarantees about
indirect storage and guaranteed reference stability, I'd hope that
container would work for *all* types.
Maybe an alternate approach makes sense?
1. Rename QList -> QArrayList.
2. Remove special case of inline storage.
3. Add QList<T> as an alias to either QArrayList<T> or QVector<T>
depending on T.
No code duplication, no change in *observed* behavior of QList, but
QList itself can be deprecated and eventually removed. (Maybe even in
6.x, since the removal is BC, and there is a work-around - declare and
specialize it yourself - for anyone that for some reason can't just
switch to QVector/QArrayList.)
And, no, I don't think std::vector<std::unique_ptr<T>> can replace
QArrayList; the item semantics are too different from std::vector<T>.
(I'd like to see a std::indirect_vector or such...)
This is precisely what I suggested previously in this thread. For Qt 6.
The discussion here is what to do in Qt 5. My opinion on this is covered
in my latest QList exit strategy that you will find in this thread, too.
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
