[Development] Proposal: Deprecate QVector in Qt 6

André Pönitz apoenitz at t-online.de
Fri Apr 24 13:51:50 CEST 2020


On Fri, Apr 24, 2020 at 09:33:49AM +0200, Christian Ehrlicher wrote:
> Am 24.04.2020 um 09:22 schrieb Lars Knoll:
> > > e "vector is a silly name from a mathematical standpoint" argument is valid,
> > > but vector is an established term in C++ world. Sorry, that ship has sailed.
> > > I am also in favor of proposal 2 or 3. I think deprecating either QList or
> > > QVector without any big advantage for the user will just make porting form
> > > Qt5 to Qt6 needlessly harder.
> > > 
> > > Even inside Qt we are struggling to keep up with deprecation warnings
> > > (Thanks to Friedemann for fixing these). I am pretty sure Creator does have
> > > the same "problem". Extrapolating that from "just us" to the broader
> > > audience we are hopefully targetting, it looks like lots of
> > > users/applications will be hit by these warnings and it will mean (lots of?)
> > > work for them.
> > I do agree that we shouldn’t deprecate neither name, as that would just make
> > moving from 5 to 6 harder. The unification of the classes should help simplify
> > things.
> > 
> > But we need to have a consistent message around which name is the preferred
> > one and used in Qt’s own API and documentation. Having a QList in one method
> > and a QVector in the next one would only be confusing to our users. So IMO
> > this thread should mainly be about deciding what the default name for this
> > container is in our documentation and API in Qt 6.
>
> Since you tell everyone since ages that QList should not be used (it's in the
> documentation since 5.6: https://doc-snapshots.qt.io/qt5-5.9/qlist.html#details

Sorry. There was never an *agreement* on the issue.

QList(<=5) was designed and implemented to be a convenient, easy-to-use
one-size-fits-all container for use cases in user facing application that was
hard to completely get wrong even for C++ newbies, including "unreasonable" use
cases like being able to access by index *and* to insert big objects in the
middle without completely killing performance.

It was never meant to be the best performing nor the smallest container for a
given fixed use case *by design*.

Consequently, it was very easy to find setups were there where better
alternatives. In fact, in almost all setups there was *some* other container
that was smaller or faster, it was "just" not always the same container.

>From that some people draw the conclusion that QList was a bad thing and started
lobbying for its demise in blog posts, conference talks and here on the mailing
list. Over time this was successful, at some time in the documentation the
comment on the default choice was flipped and for Qt 6 the implementation was
shared with QVector.

For this discussion here now the interesting consequence is that by the new
sharing of the implementation with QVector all the implementation related
arguments against QList that have been made in the past are void, all those
arguments do *not* apply to QList(>=6), at least not unless you extend them to
QVector, see below.

When you now look at the 2010 blog post you'll notice that *none* of the
performance and size claims in there apply to QList(>=6).


So what is left is the question about what is in the name. That question was
interestingly enough not present at the begin of the crusade, it only came up
after it turned out that blind replacement of QList by QVector wasn't *that*
trivial and actually caused performance regressions in real world applications,
i.e. the performance argument made against QList wasn't quite as uniformly
applicable as initially presented.

Today the main line of reasoning given is that QVector is something like
std::vector and people knowing C++ would feel comfortable using it the same way.

And that would be a false friend.

QVector is refcounted, so it *also* trades cycles (e.g. for write access) for
convenience (return by value without further decoration? No problem!) This is
still exactly the same quality of compromise QList was accused of for a decade
now, all the arguments made against compromises in principle could be made
against QVector as well.

Replacing *now* all QList uses by QVector would be a lose-lose situation. People
aiming at the ability to use a std:: container of their choice will not be
content, as it's still not a std:: container, both in name and behaviour.
Everyone else will have to adapt their code or live with the uncomfortable
feeling about not using the most recent name.

It's still possible, and easy, to limit the damage to one of the factions,
and that's what I understand is what the proposals here were aiming at.

Andre'


More information about the Development mailing list