[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