That's a deep copy. A deep copy of a string is obviously more expensive
than the overhead of calling the QString ctor and dtor.

That remains to be proven. A rule of thumb for atomics is that they're
two orders of magnitude slower than a normal int. They also still act as
optimizer firewalls. With that rule of thumb, copying 50 char16_t's is
faster than one ref-count update. What really is the deciding point is
whether or not there's a memory allocation involved. I mentioned that
for many use-cases, therefore, a non-CoW SBO container is preferable over a CoW
non-SBO one.

As stated elsewhere, the real problem about the deep copy is the allocation involved in it, not necessarily the copying of the elements.

I can't say what case is more common. What I can say is that the risk of
creating deep copies sounds worse to me than the risk of calling the
QString ctor and dtor too often.

This is what I mean with "fuzzy". We don't really have the data to
support a move to QAnyStringView for all of our API.

I can say with firm belief that, _atm_, passing QString is more common.
But this is a self-fulfilling fact. The tst_qsettings experiment shows
what can happen if you port an API that doesn't naturally receive
pre-made QStrings.

Are we in a position to change how people use our APIs? I can say with firm belief that most existing applications using Qt will not be rewritten from the ground up to avoid passing QString and QList to Qt APIs. So they will pay the cost of deep copies if we force QAnyStringView and QSpan on them by changing our API. There are lots of existing Qt applications. Your CO2 calculation doesn't look that great then.

New APIs that are not used in the "wrong" way all over the world, yet, are a different story. If we can provide a clean QAnyStringView or QSpan override without ambiguities, it's also a different story. (But adding complexity to the API is still a thing).

Maybe we can approach this in a module-by-module way. QtWidgets is probably pretty "bad" regarding QList and QString arguments, and no one will change their old widgets applications to suit our newfangled containers.

QtQml and QtQuick, on the other hand, hardly have any C++ API, and most QML and QtQuick applications are not that old. We might get away with changing API there.

QtCore and QtGui is where the most difficult decisions are to be taken, I guess.

best regards,
Ulf
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to