[Development] How qAsConst and qExchange lead to qNN

Marc Mutz marc.mutz at qt.io
Tue Nov 15 09:07:50 CET 2022


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.

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, 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())
      ~~~

Even while we wait for the circles-based GUIs to become en vogue, the 
.rects() is already more discoverable than pure QRegion-as-container.

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. They both grant the same 
freedoms and put the same constraints on the implementation of QRegion, 
but one is more flexible than the other.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B



More information about the Development mailing list