On 2019-05-17 19:47, Scott Bloom wrote:
[...]
Im just going to throw out my 2 bits on this
Please don’t underestimate (and Im not hearing Thiago say this) the
pain, of breaking source compatibility. Even on Major (5->6) version
changes.
[...]QCanvas[...]QWebKit[...]
When the Qt team, de
Fair enough..
But I will say.. all too often.. theory becomes practice
--
Please note that nobody said «we are removing Qt containers in Qt6». At least,
I don’t have that information.
The discussion is mostly about a *theoretical* case when the implementation of
a *theoretical* me
Il 17/05/19 16:46, Bernhard Lindner ha scritto:
I've done this experiment for QMap / QHash / QSet, where keeping COW at
the cost of an extra indirection (dptr -> [refcount + std:: class] ->
actual data) is more acceptable since these classes jump all over the
memory anyhow. Basically "it worked",
Please note that nobody said «we are removing Qt containers in Qt6». At least,
I don’t have that information.
The discussion is mostly about a *theoretical* case when the implementation of
a *theoretical* method in a *theoretical* class may *theoretically* change and
how far we should go to sup
On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote:
> Thiago, you partially implying that BC is still needed but with
> technologies like flatpak or snappy this will maybe not common use
> case anymore. They provide even behaviour compatibility if you stay with the
> same runtime.
> Something
On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote:
> Thiago, you partially implying that BC is still needed but with technologies
> like flatpak or snappy this will maybe not common use case anymore. They
> provide even behaviour compatibility if you stay with the same runtime.
> Something whic
Thiago, you partially implying that BC is still needed but with technologies
like flatpak or snappy this will maybe not common use case anymore. They
provide even behaviour compatibility if you stay with the same runtime.
Something which is not provided by binary compability. I personally think
My not (that) complex mobile app (game) used almost entirely QML/Javascript -
but when I needed mutual exclusion/atomicity I have not figured out anything
but going back to good, old C++...
And as mentioned below, wide variety of containers/datatypes, algorithms, etc...
So yes, perforrmance is
On Thursday, 16 May 2019 11:18:08 PDT Mutz, Marc via Development wrote:
> > When you first design the class, sure. But 5 years later, you may have
> > the
> > data internally kept in a QMap or QHash, mapped to some other
> > information. So
> > your function that used to "return d->member;" now doe
> I've done this experiment for QMap / QHash / QSet, where keeping COW at
> the cost of an extra indirection (dptr -> [refcount + std:: class] ->
> actual data) is more acceptable since these classes jump all over the
> memory anyhow. Basically "it worked", still requiring a few changes
> thou
Hi all,
Following the previous baseline, I have have updated coin production to
1.0-rc patch version 1:
https://testresults.qt.io/ci/aakeskim/production_updates/HEAD
https://testresults.qt.io/ci/aakeskim/production_updates/changelog_20190517
https://testresults.qt.io/ci/aakeskim/product
+1
Simon
From: Development on behalf of Shawn
Rutledge
Sent: Friday, May 17, 2019 14:29
To: Qt development mailing list
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status
+1
___
Development ma
+1
Simon
From: Development on behalf of Jesus
Fernandez
Sent: Friday, May 17, 2019 8:57
To: development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership
+1!
Best regards,
Jesús
From: Develop
+1
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 2019-05-17 11:36, Philippe wrote:
[...]
QVarLengthArray
While it is true that there's no such container, it's even more true
that there will never be one. Because C++ made the allocators, which
back in the 90s were just a way to handle near and far pointers on
older
architectures, fit for ac
> I start wondering if it is possible to wrap the STL containers in Qt6 and
> give them a
> nice, intuitive, Qt-like API while still providing full STL compatibility. I
> am sure this
> has been evaluated. Are the results documented somewhere?
A few years ago my application was affected by a bug
>Please watch one of Lakos' recent allocator's talks for a ton of benchmarks
>how a custom
> allocator helps speed up - not just std::vector but also std::map, if
> one is so inclined.
I fully agree with this topic (and kudos for Lakos in general).
That's actually a lack in Qt containers: no al
Il 17/05/19 09:35, Bernhard Lindner ha scritto:
I start wondering if it is possible to wrap the STL containers in Qt6 and give
them a
nice, intuitive, Qt-like API while still providing full STL compatibility. I am
sure this
has been evaluated. Are the results documented somewhere?
I've done t
On 2019-05-17 08:12, Philippe wrote:
No-one uses C++ unless they need the extra performance.
This is mostly right, though wide portability can be another reason.
This being said, that does not mean that every line of a C++
application
needs to be optimized with CPU cycles in mind.
In my expe
On Fri, May 17, 2019 at 8:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> Qt is a C++ library. If you don't like C++, either stay in QML or use
> Java. No-one uses C++ unless they need the extra performance.
>
I may or may not like where C++ is going, but that's really bes
Great that this is finally happening, hope all goes well with the upgrade!
Volker
From: Development on behalf of Jukka
Jokiniva
Sent: Friday, May 17, 2019 09:37
To: development@qt-project.org
Subject: [Development] Gerrit: Scheduled maintenance 20 May 2019
De
> you end up where the STL is - so convoluted it's hardly worth making
> anything with it.
I agree. The horrid of STL was one of the reasons for me to use Qt. Everything
is
complicated to the maximum in STL. Qt is so much more intuitive, it is fast to
learn and
fun to use (except when hitting a
Dear all,
Please read carefully, as this email contains important information.
We would like to remind you that codereview.qt-project.org will be unavailable
due to scheduled maintenance. The aim is to upgrade our Gerrit Code Review to
the latest version, 2.16. This upgrade includes a range of
Hi,
We have published IFW version 3.1.1. You can get it via online installer or
download a standalone installer. Also new versions of Qt Online Installers and
Maintenance Tools are available based on 3.1.1.
Katja Marttila
Software Engineer
The Qt Company
Elektroniikkatie 13
90590, Oulu, Finlan
+1!
Best regards,
Jesús
From: Development on behalf of Edward
Welbourne
Sent: 16 May 2019 10:58
To: Paul Wicking; development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership
Another +1.
Disclaimer: I was his mentor and offic
25 matches
Mail list logo
