https://codereview.qt-project.org/121810
So start using qMove() or pass temporaries in your QVector::append() calls.
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
On Mon, Jul 20, 2015 at 1:11 PM Thiago Macieira thiago.macie...@intel.com
wrote:
On Monday 20 July 2015 14:06:33 Marc Mutz wrote:
https://codereview.qt-project.org/121810
So start using qMove() or pass temporaries in your QVector::append()
calls.
What's the difference in std::vector
On Monday 20 July 2015 16:53:04 Knoll Lars wrote:
Most likely, we should change QList in Qt 6 to simply share it’s
implementation with QVector and make them both compatible, but we
unfortunately can’t do this right now.
I'd rename it QArrayList and have it always operate in new'ed-up-items
On Monday 20 July 2015 14:06:33 Marc Mutz wrote:
https://codereview.qt-project.org/121810
So start using qMove() or pass temporaries in your QVector::append() calls.
What's the difference in std::vector between an rvalue push_back and
emplace_back?
--
Thiago Macieira - thiago.macieira (AT)
Let’s at least fix the docs. It won’t keep people from
choosing QList because the type is so pervasive in Qt’s API, but at least
we’re then giving better advice.
https://codereview.qt-project.org/#/c/121674/
martin
From:
On Monday 20 July 2015 18:25:43 Keith Gardner wrote:
What's the difference in std::vector between an rvalue push_back and
emplace_back?
emplace_back takes variadic template arguments to construct the item
directly in the vector instead of creating a temporary and then performing
a move
On Monday 20 July 2015 22:01:01 Marc Mutz wrote:
I'd rename it QArrayList and have it always operate in new'ed-up-items mode.
That container is not available from the STL (though vectorunique_ptr
comes close), so I'm ok with keeping it. But then it must _always_ new up
items, even bools,
Milian Wolff wrote:
Did you actually profile this? I don't see how a QVector could lead to
allocation hell, where QList would not be much worse.
If you have large objects, and insert or remove items within the list,
QVector will have to move (or even copydelete, if they're not movable)
large
Randall O'Reilly wrote:
I’m surprised nobody has mentioned that, because of the private data
nature of most Qt classes, they are a) already allocating the private data
object on the heap all the time and incurring all that overhead and memory
allocation badness, and b) are essentially a
Smith Martin wrote:
And apparently QVector has the same API as QList now, so why don't we
deprecate QList. Let it always create a QVector.
Because that would fail the performance promises in the QList documentation.
QVector is NOT always more efficient.
Kevin Kofler
On 07/18/15 04:54, Knoll Lars-san wrote:
Can you explain what the advantage of moving it out would be?
The ibus input context was originally developed by me when we ported from Qt
4 to Qt 5. I tried to implement it with a minimum set of dependencies. It's
IMO still important to have in the
On Tuesday 21 July 2015 02:26:41 Kevin Kofler wrote:
For the implicitly shared data types, QList actually does NOT add another
layer of indirection (as documented: If T is itself a pointer type or a
basic type that is no larger than a pointer, or if T is one of Qt's shared
classes, then
On Tuesday 21 July 2015 02:57:34 Kevin Kofler wrote:
Marc Mutz wrote:
I maintain that because of that Janus-headedness of QList, QList should
be avoided at any cost for types for which it has not already been
established as public API, even if the alternatives, QVector or
QLinkedList,
13 matches
Mail list logo
