mwoehlke.floss at gmail.com
Tue Apr 25 20:45:12 CEST 2017
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
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...)
More information about the Development