Hi,
This is true. xmlpatterns is still on the Jenkins based CI. It's one of the few
modules we haven't moved over yet,
due to the way it "tests" (well, the truth is that it doesn't actually run any
blocking tests, for years :)
I see two options:
(1) Land that change to qtqa/testconfig.
(2) Wa
http://testresults.qt.io/ci/QtXmlPatterns_dev_Integration/build_00123/macx-clang_no-framework_OSX_10.8/log.txt.gz
http://testresults.qt.io/ci/QtXmlPatterns_dev_Integration/build_00125/macx-clang_developer-build_OSX_10.9/log.txt.gz
Both failed at:
+ /work/build/qt/qtbase/configure -top-level -no-p
On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote:
> > * We need at least one input context to use and test against (on Linux)
> > when developing Qt further. Not having the plugin in qtbase will lead to
> > us not testing IMEs on Linux anymore, something I really want to avoid.
>
> I think you
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
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:48:12 Kevin Kofler wrote:
> IMHO, QList is the safest container to recommend to an inexperienced
> programmer, because there are very few operations that have a suboptimal
> complexity class. (Of course, abuse of contains or indexOf/lastIndexOf
> where a QHash or QMap
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
> > QLinkedL
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, depending on the kind of container you wanted QList to be,
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 copy&delete, if they're not movable)
la
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
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 poi
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 vector
> comes close), so I'm ok with keeping it. But then it must _always_ new up
> items, even bools, otherwise yo
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
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 m
On Mon, Jul 20, 2015 at 1:11 PM Thiago Macieira
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 between an rvalue p
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: development-bounces+martin.smit
On 13/07/15 10:34, "Giuseppe D'Angelo" wrote:
>Il 12/07/2015 23:19, Alejandro Exojo ha scritto:
>> El Sunday 12 July 2015, Thiago Macieira escribió:
>>> On Sunday 12 July 2015 16:16:07 Smith Martin wrote:
I can see by your explanation that QVector is almost always more
efficient than QL
https://codereview.qt-project.org/121810
So start using qMove() or pass temporaries in your QVector::append() calls.
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
19 matches
Mail list logo
