[Development] How qAsConst and qExchange lead to qNN
marc.mutz at qt.io
Mon Nov 14 21:53:19 CET 2022
On 14.11.22 18:11, Thiago Macieira wrote:
> On Monday, 14 November 2022 08:22:44 PST Marc Mutz via Development wrote:
>> Can we agree that NOI for setters is a no-brainer? Then 90% of the
>> usefulness of NOI can already be reaped, in a BC and SC manner. There's
>> pretty little we can do with return values before Qt 7, except use the
>> stuff in private APIs to try it out. But we can and should convert
>> setters already.
> Not without conditions.
> I can agree with that so long as it doesn't remove the ability to add the
> owning equivalent as overload, even if it is a Q_WEAK_OVERLOAD, where it
> benefits because the target code is going to store anyway.
_If_ and for as long as the class stores the data in _that_ owning
container, fine by me. That'll probably be the case for Qt 6 going
forward, because of those pesky owning container return types.
That said, I repeat that the goal here needs to be to let each class
choose its own optimal data structure, and for a large class of cases
that would be QVLA/llvm::SmallVector, iow: _something_ with a small
As long as we have an implicitly-shared everywhere policy, it's CoW on
top of CoW on top of CoW. If the QRegionData/Private is ref-counted,
then it makes little sense to contain the QRects in a container that's
_also_ CoW. Nothing is using the implict sharedness of the QRect
container (rects() is gone in 6.0, and can be re-used for a QSpan<const
> I don't think we will ever change return types.
Your short interjections would be more valuable if you didn't just state
an opinion, but also give rationale ;-)
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
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