[Development] How qAsConst and qExchange lead to qNN

Marc Mutz marc.mutz at qt.io
Tue Nov 15 10:42:55 CET 2022


On 14.11.22 22:17, Thiago Macieira wrote:
> On Monday, 14 November 2022 12:53:19 PST Marc Mutz via Development wrote:
>>> 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 ;-)
> 
> That's why I said "I think".
> 
> We can't return a non-owning view because that requires that we store
> internally *as* a contiguous area.

The "stored" here is much more of a constraint than the "contiguous". 
Even associative containers can be contiguous (QFlatMap, or a sorted 
vector or struct { key, value }). But I wrote that for non-stored or 
non-contiguous coroutines returning generators can be used. No-one 
suggests to use spans for non-stored or non-contiguous data, so this a 
straw man.

> If we are already doing that, we can store
> as QList and return *as* QList with implicit sharing.

In comparison, returning a QList requires us to store a QList. This is 
objectively a stronger constraint than merely string contiguous data. 
It's also a substantial constraint, as it excludes SBO, like in the 
QRegion case.

> Returning as an iteratable interface requires that we return a proxy object,
> like QRegularExpressionMatch, so that the solution is thread-safe. This is
> neither simple to understand, to code, or to port existing code over to. It
> also requires copying the data over (hopefully, implicitly) to the proxy
> object, so it doesn't solve anything.

I disagree on all points. QREM is complicated because we need to 
shoehorn a coroutine into an iterator concept. Same with 
QStringTokenizer. Coroutines with lazy sequences (generator<>) are very easy to implement and use.

If we're to discuss further, please watch my Meeting C++ presentation, 
which lays out all the pros and cons I'm aware of. No need to re-iterate 
them in text here. https://youtu.be/tvdwYwTyrig

See esp. https://youtu.be/tvdwYwTyrig?t=1219 for how trivial a QREMatch 
becomes when coroutines are available.

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