[Development] How qAsConst and qExchange lead to qNN
giuseppe.dangelo at kdab.com
Tue Nov 15 03:32:36 CET 2022
Il 10/11/22 20:27, Thiago Macieira ha scritto:
>> (We end up with these overload sets because right now we have tons of
>> f(QString), and we're slowly moving them to f(QStringView) if it does
>> make sense for them. Due to the BC promise we can't just_remove_
> And we shouldn't. So we shouldn't be moving to QStringView.
> Where it's useful, we can use a Q_WEAK_OVERLOAD. But I insist that we only do
> that where there's a clear performance benefit. Otherwise, keep using QString.
I'm not sure what is meant here. I was just pointing out that
overloading a function with QString and QStringView (or QAnyStringView
for that matter) is just a historical accident:
* we have an "old" API that takes QString
* we realize it doesn't _have to_ (e.g. string never stored, etc.)
* we want to replace it with a "newer" API that takes QStringView. We
can't literally *replace* it (binary, and also, minor, source
compatibility). So we have to add a QStringView overload and keep both
for the entire major version.
* Now, if we have a QString(const char16_t *) constructor, this
overloading break SC when someone calls the API with a u"" literal, and
But the point is that if we developed the API from scratch today, we'd
likely not even had the QString overload to begin with -- we would have
averted the whole issue.
We've found a robust solution to this problem via the removed_api
mechanism, which is going to keep the QString overload, but hide it from
clients. (At least, I *think*.) This will make calls passing u""
literals to keep working just fine. So what other concern is there for
not allowing this QString construction?
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4244 bytes
Desc: Firma crittografica S/MIME
More information about the Development