[Development] HEADS-UP: Branching from '6.4' to '6.4.2' done
Good morning! We have branched '6.4.2' from '6.4' now and so on all changes targeted to Qt 6.4.2 release must have 'Pick-to: 6.4.2' and '6.4' is for Qt 6.4.3 release. As usual staging in '6.4.2' will be restricted to release team only and we will monitor and stage needed changes automatically there. Target is to release Qt 6.4.2 mid December 2022. Br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Multi-subarch update
Hello all A few of us have just had a call to discuss what we're going to do for the functionality I proposed for 6.5. Here are our conclusions and proposals. First, we're going to postpone this to 6.6, on account of feature freeze being too close. While I think the risk is minimal for non-Linux architectures, I might have broken things I don't know about. And there's also a risk for Linux where we accidentally and silently mis-compile something and it only fails at runtime. So this requires more eyes and more time. Second, the code I developed is ugly. And it's fragile, leading to the potential issues mentioned above. Instead, Alexandru had a different idea on how to do this, which matches what we're doing for the Android Multi-ABI support, which could then be extended to the macOS universal builds. Details on this on a separate email. But we'd like to try this alternate solution instead and see if it is more resilient than what I did. For this alone, we need more time. Third, there's the question of compile time and whether it's worth the cost for all libraries (cost in time to build as well as installed size). I did this for every single Qt module library, but my intention was to add an option so a few libraries' CMakeLists.txt files could opt in, leaving it disabled for everything else, which further reduces the risk by reducing the problem surface. To make a choice, we'll need a metric, to be determined. My guesstimate is that it will be worth for our three traditional core libraries (QtCore, QtGui, QtWidget), the two Qml core libraries (QtQml and QtQuick), and the Qt3D Core and Render libraries. It's not a coincidence that the five biggest libraries of our own code are also the first five I listed here; maybe #7 (QtQuick3DPhysics) could be there too. Fourth, there's the Qt3D qmake code. I was surprised to find out that qt3d 6.x module was meant to compile with Qt 5's qmake. This is not tested in our CI, I believe. I don't think any Linux distributions know about this, either. So who's using it? We need a decision going forward whether this support shall remain, in particular as Qt 6.5 should be a Commercial LTS, so 6.6 is a good point for dropping some compatibility. Jörg, Tor Arne, Alexandru, Kai, Alexey, anything I forgot? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How qAsConst and qExchange lead to qNN
On Wed, Nov 16, 2022 at 09:50:35AM -0800, Thiago Macieira wrote:
> On Tuesday, 15 November 2022 23:50:38 PST Marc Mutz via Development wrote:
> > > in a thread-safe manner (such that if something in
> > > the same thread or another thread-safely modifies that map, the original
> > > user isn't affected).
> >
> > The above isn't thread-safe, it isn't even re-entrant, in the same way
> > that iteration using iterators isn't. This is a known issue whenever you
> > hand out references, and it's nothing that violates our
> > const-is-thread-safe promise,
>
> No, but it moves the responsibility for avoiding this problem to the user.
>
> Right now, you can do:
> for (auto elem : object.keyList()) {
> operate(); // may recurse back into object and modify it
> }
>
> If you use a generator paradigm to return this key list, then the *user* must
> know that they must create a local container with the items to be generated
> and iterate over that. Performance-wise, this no different than if the Qt
> code
> created the container and returned it, but it has two drawbacks:
>
> 1) the responsibility for knowing this
>
> 2) if the Qt object already has a QList with this, then using a generator
> paradigm enforces the need of a deep copy, when implicit would have been
> cheaper
Exactly.
The only *safe* *and* *conveniently uniform* (a.k.a. "worth to have on a
Qt API level") use of a generator as return value (e.g. something that's
easily put into a delayed call) is to effectively store a full copy of
the later generated elements /somewhere/ or otherwise make sure that the
base object's lifetime or at least a subset of it that is capable to
create the elements is extended until the generator object dies (e.g.
by having some kind of ref count and COW on itself).
Currently this "storing of a full copy" is bumping a reference count
on an already existing Qt container, or creating one from scratch,
including a deep copy. In the envisioned new world, this would always
be an immediate full copy.
> > > Because you pointed to QStringTokenizer and that implicitly-
> > > copies a QString.
> >
> > That's imprecise. QStringTokenizer extends rvalue lifetimes ("rvalue
> > pinning") so's to make this safe:
> >
> > for (auto part : qTokenize(label->text(), u';'))
>
> BTW, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2012r2.pdf is
> accepted for C++23 and moves the end of the temporaries' lifetimes to the end
> of the full for statement.
>
> Though we still need to work with C++17 and 20 for a while.
>
> Also, sometimes I wonder if all the work you and I do to optimise these
> things
> matter, in the end. We may save 0.5% of the CPU time, only for that to be
> dwarfed by whatever QtGui, QtQml are doing.
The Qt Project has easy access to a not completely trivially-sized test
bed for API experiments which has stability promises one magnitude less
and potential damage done to downstream dependencies several magnitudes
less than similar activities in QtBase: Qt Creator. Interested parties
could just check out the sources, and start running experiments without
being bound to long-term API contract and with simple reverts at hand
when experiments fail.
I can even give a hint where to start: A rather heavily used string-ish
class is Utils::FilePath, and there are at least half a dozen "obvious"
candidates for an NOI: E.g. .suffix() currently returns a QString that
is /always/ a copy of a part of the underlying storage, so according to
my understanding this "obviously" would "have to be" a QStringView in a
"new world" API.
I'd be happy to see the results of the experiment from someone who
thinks this kind of API is a good idea in the form of profiler results
and consequences for uses of this API in "user" code. [I know mine.]
Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] How qAsConst and qExchange lead to qNN
On Tue, Nov 15, 2022 at 08:07:50AM +, Marc Mutz via Development wrote: > On 14.11.22 23:04, A. Pönitz wrote: > >> Marc’s proposal of a Non-Owning Interface is already > >> become manifest in QRegion::begin/end > >> > >> https://doc.qt.io/qt-6/qregion.html#begin > >> > >> allowing us to write > >> > >> > >> for (auto rect : region) doSomethingWith(rect); > > Yes, and that's fine [but not quite matching the rest of the discussion > > of using spans?] > > > >> (while QRegion::rects will have to create a QList even if there is > >> only a single rect in the inline storage, which is then not a QList). > >> > >> This is a*good* addition to Qt. I think we can make more such > >> additions to Qt, in places where it makes a real difference for > >> today’s client code using owning containers, and without changing the > >> world. > > Fine with me. > > > > With emphasis on "addition" and "real", and notable absense of "change" > > and "removal"... > > QVector QRegion::rects() const _was_ removed for Qt 6.0. I was referring to the introduction of begin() and end(). The removal of QVector QRegion::rects() const was not needed, but did not particular hurt. > The trick to treat QRegion as a container of QRect, simplifying both > users and implementation of QRegion (no more vectorize()), only worked > because QRegion is home to only one collection. It's also a trick you > need to see to be able to use it, I don't think so. > so discoverability is poor. In the > general case, a given class may have more than one collection of items. > E.g. if circular windows became the new rage, QRegion could be a > collection not just of rects, but also of ellipses. Then what? > > Enter span-retuning getters: > > for (QRect rect : region.rects()) > ~~~ > for (QEllipse ell : recion.ellipses()) > ~~~ Or return per-type proxy-objects implementing begin() and end(). > [..] > There's a logical incompatibility between "QRegion as a QRect container > = good" and "QRection::rects() returning a span of QRect = bad". > > Either both are good ideas or neither are. No. The idea is that QRegion can be anything it want to /internally/, but there's a way to consider is as a container of QRects. > They both grant the same freedoms and put the same constraints on the > implementation of QRegion, but one is more flexible than the other. Returning a span requires a container somewhere /and/ adds the implicit requirement to the lifetime of this storage. It is putting /more/ constraints on the implementation of QRegion. The container-returning one is more flexible as this can be either a container that's part of the structure, or be created on-the-fly. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
