Hi,
On 23-04-20 11:58, Jaroslaw Kobus wrote:
There are cases, where the name of the function contains the "list", like:
QList<QMdiSubWindow *> QMdiArea::subWindowList(QMdiArea::WindowOrder order =
CreationOrder) const;
QList<QPair<qreal, QPointF> > QGraphicsItemAnimation::translationList() const;
QList<QLowEnergyAdvertisingParameters::AddressInfo>
QLowEnergyAdvertisingParameters::whiteList() const;
etc...
So, subWindowList() returning the vector?
Yeah. Not ideal, but not a big deal either in these cases, especially
the last one which uses a common term "whiteList". I do see an issue
with API like QSet::toList(). That would obviously need to be deprecated
in favor of a QSet::toVector().
André
Changing QList to QVector may in consequence require even more API changes.
Jarek
________________________________________
From: Development <development-boun...@qt-project.org> on behalf of André Somers
<an...@familiesomers.nl>
Sent: Thursday, April 23, 2020 11:21 AM
To: development@qt-project.org
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
Hi Simon,
On 23-04-20 10:55, Simon Hausmann wrote:
Hi,
So take for example this function in QIconEngine:
virtual QList<QSize> availableSizes(QIcon::Mode mode = Icon::Normal,
QIcon::State state = QIcon::Off) const;
If we change that to QVector, we require our users to clutter their code base
with #ifdefs. If we keep it with QList but use QVector in all non-virtual
functions, then we create a less consistent API.
Do you think the #ifdefs or inconsistency is worth the proximity to the
standard? (despite QVector not being like std::vector due to CoW semantics)
I may be missing the obvious, but I really fail to see the problem if you
change the signature to
virtual QVector<QSize> availableSizes(...);
If we have that
template<typename T> using QList = QVector<T>;
a subclass reimplementing using QList should just work in both Qt5 and Qt6,
right? So what #ifdef's would be needed?
And yes, I _do_ think staying close to the established meaning of what is a
vector and what is a list is good. Getting list of QList (which is not a list)
brings us closer to that goal.
André
Simon
________________________________
From: Daniel Engelke
<daniel.enge...@basyskom.com><mailto:daniel.enge...@basyskom.com>
Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann <simon.hausm...@qt.io><mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto:development@qt-project.org>
<development@qt-project.org><mailto:development@qt-project.org>
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
Hi Simon,
I think having a name that is close to the standard is very important as it
makes it easy to find the Qt counterpart.
Back in the days I had to ask a StackOverflow question to find Qts unique_ptr
(QScopedPointer), because I couldn't find it due to the naming.
Dmitriy also has a very valid point. It is burned in a lot of peoples heads
that using QList is a bad idea.
I don't see a lot of work in string replacing QList with QVector and
QStringList with whatever it would be, as long as the API is compatible.
It's even less work if auto has been used.
Dan
From: Simon Hausmann <simon.hausm...@qt.io><mailto:simon.hausm...@qt.io>
To: Dmitriy Purgin <dpur...@gmail.com><mailto:dpur...@gmail.com>
Cc: "development@qt-project.org"<mailto:development@qt-project.org>
<development@qt-project.org><mailto:development@qt-project.org>
Sent: 4/23/2020 10:27 AM
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
Hi Dmitriy,
No, this is not an April's Foolk joke.
Previous discussions were largely centred around the implementations and
bringing them together. With this thread my concern is the API and the churn
our users would have to apply to their code base in order to use Qt 5 and Qt 6.
Simon
________________________________
From: Dmitriy Purgin <dpur...@gmail.com><mailto:dpur...@gmail.com>
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann <simon.hausm...@qt.io><mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto:development@qt-project.org>
<development@qt-project.org><mailto:development@qt-project.org>
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
Hi Simon,
I hope it's not a belated April's Fool joke? As far as I can remember, for the
past few years, one would read everywhere to switch to QVector from QList
because of this and that, and to choose QVector as the default choice container
instead of QList like it was back in the days. I can't give the exact
references but that's just the feeling I get from reading the docs and the Qt
mailing lists.
Cheers
Dmitriy
On Thu, Apr 23, 2020 at 9:45 AM Simon Hausmann
<simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> wrote:
Hi,
In dev we've had QVector being an alias for QList for a while now. For the 6.0
release this particular topic (QList/QVector) suggests two goals (among others):
(1) Use the same type throughout the public API of Qt.
(2) Make it easy for our users to maintain a code base that works with Qt
5 and 6.
In the light of those two goals, I think we should keep using QList as the type
in the public API. I don't think we should do a search and replace activity and
switch to QVector. In the light of that, I would like to propose simply
deprecating QVector and stick to QList everywhere.
What do you think?
Simon
_______________________________________________
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
