[Development] How qAsConst and qExchange lead to qNN
apoenitz at t-online.de
Tue Nov 15 18:44:39 CET 2022
On Tue, Nov 15, 2022 at 08:07:50AM +0000, 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<QRect> QRegion::rects() const _was_ removed for Qt 6.0.
I was referring to the introduction of begin() and end().
The removal of QVector<QRect> 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.
More information about the Development